On 14/08/2025 8:37 pm, Nicola Vetrini wrote: > On 2025-08-14 13:47, Andrew Cooper wrote: >> On 14/08/2025 12:44 pm, Jan Beulich wrote: >>> On 14.08.2025 13:42, Andrew Cooper wrote: >>>> On 14/08/2025 12:20 pm, Jan Beulich wrote: >>>>> On 08.08.2025 22:23, Andrew Cooper wrote: >>>>>> --- a/xen/arch/x86/include/asm/x86-defns.h >>>>>> +++ b/xen/arch/x86/include/asm/x86-defns.h >>>>>> @@ -75,6 +75,7 @@ >>>>>> #define X86_CR4_PKE 0x00400000 /* enable PKE */ >>>>>> #define X86_CR4_CET 0x00800000 /* Control-flow >>>>>> Enforcement Technology */ >>>>>> #define X86_CR4_PKS 0x01000000 /* Protection Key >>>>>> Supervisor */ >>>>>> +#define X86_CR4_FRED 0x100000000 /* Fast Return and Event >>>>>> Delivery */ >>>>> ... a UL suffix added here for Misra. >>>> I was surprised, but Eclair is entirely fine with this. >>> And there is a use of the identifier in a monitored C file? >> >> Yes. traps-setup.c which definitely has not been added to an exclusion >> list. >> > > Might look into it before the end of the week, if time allows. Is [1] > the right branch to look at? > > [1] > https://gitlab.com/xen-project/hardware/xen-staging/-/commits/andrew/fred
Yes, although I am force pushing this with fixes as I find them. In the latest run at the time of writing, I had one trivial R8.4 violation to fix, and all other clean rules came up fine. I expect the next run to be clean. One thing that might be relevant, IIRC it's implementation defined behaviour what happens to constants which are wider than int to begin with. ~Andrew
