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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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?

~Andrew