Re: [PATCH 09/12] x86/shadow: Rework write_atomic() call in shadow_write_entries()

[Nicola Vetrini <nicola.vetrini@bugseng.com>]

On 2026-02-25 13:53, Andrew Cooper wrote:
> On 25/02/2026 12:35 pm, Nicola Vetrini wrote:
>> On 2026-02-25 13:14, Andrew Cooper wrote:
>>> On 23/02/2026 7:26 am, Roberto Bagnara wrote: 
>>>> 
>>>> Note that in recent versions of MISRA C that rule is no longer
>>>> mandatory.  More generally, note also that, IMHO, switching to
>>>> a more modern version of MISRA C would simplify compliance.
>>> 
>>> Ok.  Making things simpler for compliance sounds like a good thing. 
>>> What would this entail?
>>> 
>>> Presumably we've got to adapt to all changes in this newer revision 
>>> of
>>> MISRA C.
>>> 
>>> ~Andrew
>> 
>> Most likely new violations on new non-clean guidelines, generally
>> rules for features that were standardized in C11/C18 and were
>> previously widely available extensions (e.g. _Noreturn, _Alignof,
>> threads, ...), 
> 
> We use noreturn a lot, and alignof() a little.  No threading at all
> (well - not as C understands it).
> 
>> alongside some minor changes in existing ones, such as the
>> classification change mentioned by Roberto. The exact impact depends
>> on the target MISRA revision, however. Making an experiment should be
>> only a matter of s/MC3A2/MC4/ (or whichever MISRA revision is chosen:
>> MC4 in ECLAIR refers to the latest published MISRA revision, that is,
>> MISRA C:2025. Perhaps also a few regressions (as in newly introduced
>> violations) on clean ones, but I do not expect the results to be
>> radically different.
>> 
>> Side note here: are the efforts to make Xen compile with
>> -stc=c11/gnu11 still ongoing? I say this because any MISRA revision
>> other than the one currently used by Xen by default is based on C11,
>> as it introduces guidelines for C11/C18 features. Not that this would
>> matter a whole lot for Xen, but it is something to consider in the
>> broader picture.
>> 
> 
> Funny you should ask.  I had a paragraph about it in my reply but
> dropped it, thinking it was getting off track.
> 
> https://gitlab.com/xen-project/xen/-/issues/201
> 
> I've just updated it to note that we did start using auto, by way of 
> the
> __auto_type language extension.
> 
> From the Xen side, switching to gnu11 is a one-line change.  However
> "ongoing" is really just me in my copious free time, and I'm not able 
> to
> do the ECLAIR/MISRA config side of the work.
> 
> It sounds to me like we want a dedicated work item switch to gnu11 and
> some newer MISRA revision, but I will have to defer to you on how large
> a task this is.
> 
> I suppose we should start with an experiment to see what shows up in 
> the
> *-amd target builds, and go from there?
> 

Yes, that's sensible. I just wasn't sure if there were other gotchas in 
Xen still to be addressed before using gnu11

> ~Andrew

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253