On 19/10/2023 1:54 am, Stefano Stabellini wrote:
> On Thu, 19 Oct 2023, andrew.coop...@citrix.com wrote:
>> On 18/10/2023 2:42 pm, Nicola Vetrini wrote:
>>> diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
>>> index ee7aed0609d2..1b00e4e3e9b7 100644
>>> --- a/docs/misra/deviations
On 18/10/2023 2:42 pm, Nicola Vetrini wrote:
> diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
> index ee7aed0609d2..1b00e4e3e9b7 100644
> --- a/docs/misra/deviations.rst
> +++ b/docs/misra/deviations.rst
> @@ -199,6 +199,11 @@ Deviations related to MISRA C:2012 Rules:
>
On 11/10/2023 7:34 pm, David Woodhouse wrote:
>> On 16/01/2020 16:00, Igor Druzhinin wrote:
>>> Due to AMD and Hygon being unable to selectively trap CR4 bit modifications
>>> running 32-bit PV guest inside PV shim comes with significant performance
>>> hit. Moreover, for SMEP in particular every t
On 11/10/2023 8:46 pm, Nicola Vetrini wrote:
> diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
> index ee7aed0609d2..1b00e4e3e9b7 100644
> --- a/docs/misra/deviations.rst
> +++ b/docs/misra/deviations.rst
> @@ -199,6 +199,11 @@ Deviations related to MISRA C:2012 Rules:
>
On 06/10/2023 2:07 am, Stefano Stabellini wrote:
> On Thu, 5 Oct 2023, Nicola Vetrini wrote:
>> The constant 0 is used as a null pointer constant, in
>> violation of MISRA C:2012 Rule 11.9, in builds with
>> CONFIG_DEBUG_LOCK_PROFILE defined.
>>
>> Signed-off-by: Nicola Vetrini
> Reviewed-by: Stef
On 06/10/2023 9:26 am, Nicola Vetrini wrote:
> The definition of MC_NCLASSES contained a violation of MISRA C:2012
> Rule 10.1, therefore by moving it as an enumeration constant resolves the
> violation and makes it more resilient to possible additions to that enum.
>
> Signed-off-by: Nicola Vetrin
On 06/10/2023 9:26 am, Nicola Vetrini wrote:
> diff --git a/xen/include/xen/macros.h b/xen/include/xen/macros.h
> index d0caae7db298..bb9a1c9a53d0 100644
> --- a/xen/include/xen/macros.h
> +++ b/xen/include/xen/macros.h
> @@ -8,8 +8,10 @@
> #define DIV_ROUND(n, d) (((n) + (d) / 2) / (d))
> #defin
On 03/10/2023 9:46 pm, Stefano Stabellini wrote:
> On Tue, 3 Oct 2023, Nicola Vetrini wrote:
>> As specified in rules.rst, these constants can be used
>> in the code.
>> Their deviation is now accomplished by using a SAF comment,
>> rather than an ECLAIR configuration.
>>
>> Signed-off-by: Nicola V
On 03/10/2023 4:37 pm, Nicola Vetrini wrote:
> As specified in rules.rst, these constants can be used
> in the code.
> Their deviation is now accomplished by using a SAF comment,
> rather than an ECLAIR configuration.
>
> Signed-off-by: Nicola Vetrini
> ---
> automation/eclair_analysis/ECLAIR/dev
On 26/09/2023 9:10 am, Nikolay Borisov wrote:
> On 23.09.23 г. 12:41 ч., Xin Li wrote:
>> diff --git a/arch/x86/include/asm/trapnr.h
>> b/arch/x86/include/asm/trapnr.h
>> index f5d2325aa0b7..8d1154cdf787 100644
>> --- a/arch/x86/include/asm/trapnr.h
>> +++ b/arch/x86/include/asm/trapnr.h
>> @@ -2,6
On 25/09/2023 10:11 am, Nicola Vetrini wrote:
> diff --git a/xen/include/xen/vga.h b/xen/include/xen/vga.h
> index f72b63d446b1..9b2c47971d0c 100644
> --- a/xen/include/xen/vga.h
> +++ b/xen/include/xen/vga.h
> @@ -13,6 +13,12 @@
>
> #ifdef CONFIG_VGA
> extern struct xen_vga_console_info vga_co
On 15/09/2023 1:38 am, H. Peter Anvin wrote:
> On 9/14/23 17:33, andrew.coop...@citrix.com wrote:
>>
>> It's an assumption about what "definitely won't" be paravirt in the
>> future.
>>
>> XenPV stack handling is almost-FRED-like and has been for the better
>> part of two decades.
>>
>> You frequen
On 15/09/2023 2:01 am, H. Peter Anvin wrote:
> The whole bit with alternatives and pvops being separate is a major
> maintainability problem, and honestly it never made any sense in the
> first place. Never have two mechanisms to do one job; it makes it
> harder to grok their interactions.
This bi
On 15/09/2023 1:12 am, Thomas Gleixner wrote:
> On Fri, Sep 15 2023 at 00:46, andrew wrote:
>> On 15/09/2023 12:00 am, Thomas Gleixner wrote:
>>> So no. I'm fundamentally disagreeing with your recommendation. The way
>>> forward is:
>>>
>>> 1) Provide the native variant for wrmsrns(), i.e. rename
On 15/09/2023 12:00 am, Thomas Gleixner wrote:
>> and despite what Juergen said, I'm going to recommend that you do wire
>> this through the paravirt infrastructure, for the benefit of regular
>> users having a nice API, not because XenPV is expecting to do something
>> wildly different here.
> I f
On 14/09/2023 5:47 am, Xin Li wrote:
> Intel VT-x classifies events into eight different types, which is
> inherited by FRED for event identification. As such, event type
> becomes a common x86 concept, and should be defined in a common x86
> header.
>
> Add event type macros to , and use it in .
>
On 14/09/2023 5:47 am, Xin Li wrote:
> Add an always inline API __wrmsrns() to embed the WRMSRNS instruction
> into the code.
>
> Tested-by: Shan Kang
> Signed-off-by: Xin Li
> ---
> arch/x86/include/asm/msr.h | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/arch/x86/
On 14/09/2023 7:09 am, Jan Beulich wrote:
> On 14.09.2023 08:03, Juergen Gross wrote:
>> On 14.09.23 06:47, Xin Li wrote:
>>> From: "H. Peter Anvin (Intel)"
>>>
>>> Any FRED CPU will always have the following features as its baseline:
>>>1) LKGS, load attributes of the GS segment but the base
On 14/09/2023 7:02 am, Juergen Gross wrote:
> On 14.09.23 06:47, Xin Li wrote:
>> Add an always inline API __wrmsrns() to embed the WRMSRNS instruction
>> into the code.
>>
>> Tested-by: Shan Kang
>> Signed-off-by: Xin Li
>
> In order to avoid having to add paravirt support for WRMSRNS I think
>
On 03/05/2023 10:53 pm, Stefano Stabellini wrote:
> On Wed, 3 May 2023, Julien Grall wrote:
>> On 03/05/2023 15:38, andrew.coop...@citrix.com wrote:
>>> Hello,
>>>
>>> After what seems like an unreasonable amount of debugging, we've tracked
>>> down exactly what is going wrong here.
>>>
>>> https:/
On 03/05/2023 4:22 pm, Juergen Gross wrote:
> On 03.05.23 17:15, Julien Grall wrote:
>> Hi,
>>
>> On 03/05/2023 15:38, andrew.coop...@citrix.com wrote:
>>> Hello,
>>>
>>> After what seems like an unreasonable amount of debugging, we've
>>> tracked
>>> down exactly what is going wrong here.
>>>
>>>
Hello,
After what seems like an unreasonable amount of debugging, we've tracked
down exactly what is going wrong here.
https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/4219721944
Of note is the smoke.serial log around:
io: IN 0x90fec250 d0 20230503 14:20:42 INTRODUCE (1 233473 1 )
o
On 29/04/2023 2:34 pm, Marek Marczykowski-Górecki wrote:
> On Sat, Apr 29, 2023 at 12:41:26PM +0100, andrew.coop...@citrix.com wrote:
>> On 29/04/2023 4:05 am, Stefano Stabellini wrote:
>>> On Fri, 28 Apr 2023, GitLab wrote:
Pipeline #852233694 triggered by
[568538936b4ac45a343cb3a4ab0c6c
On 29/04/2023 4:05 am, Stefano Stabellini wrote:
> On Fri, 28 Apr 2023, GitLab wrote:
>> Pipeline #852233694 triggered by
>> [568538936b4ac45a343cb3a4ab0c6cda?s=48&d=identicon]
>> Ganis
>> had 3 failed jobs
>> Failed jobs
>> ✖
>> test
>> qemu-smoke-dom0less-arm64-gcc
> This is a real failure on sta
24 matches
Mail list logo
