From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 6B0F0FD3758 for ; Wed, 25 Feb 2026 13:09:57 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.1240745.1542026 (Exim 4.92) (envelope-from ) id 1vvEe7-0008K2-0a; Wed, 25 Feb 2026 13:09:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1240745.1542026; Wed, 25 Feb 2026 13:09:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vvEe6-0008Jv-UE; Wed, 25 Feb 2026 13:09:42 +0000 Received: by outflank-mailman (input) for mailman id 1240745; Wed, 25 Feb 2026 13:09:42 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vvEe6-0008Jp-Ct for xen-devel@lists.xenproject.org; Wed, 25 Feb 2026 13:09:42 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 3e2c0186-124b-11f1-9ccf-f158ae23cfc8; Wed, 25 Feb 2026 14:09:40 +0100 (CET) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) (Authenticated sender: nicola) by support.bugseng.com (Postfix) with ESMTPA id 475754EE7811; Wed, 25 Feb 2026 14:09:39 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3e2c0186-124b-11f1-9ccf-f158ae23cfc8 Authentication-Results: bugseng.com; arc=none smtp.remote-ip=162.55.131.47 ARC-Seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1772024979; b=toAJGV4kmjabV7WLfmxtdNs9k1d2Lwhmo4tUgvobbMMOZfwtOO5P2UNNaMAfF44/FNct U3/JJgPZC4gMYptoZdK9ZQawNfxG5DPNFCdxTA9Wq7dwyrR19c78QMitPgkI3+IqbHOzG YyMVGkRskik+IBpkSgG3Cd4GzbCRQ+on1mUFbLsQ3S9JOzWErddIBk+8X3Snuc/T6EvT+ rlZEIS8R6W3LhIJk1917svuRvyWoPsNCvFPdjwnFevoHHIeDSIuvpD4adD+qLYjoICXEf NFj3bKL7i/OSoqpCD1rouyPELXbMi6AEYDFp+kJDcd4tibmR4NFhe7wx4ugPiCAHBFAjL z6jeeZp2adfyNc74ahlG6l5sJfc1U/o5pQOP8dhck5GhtiTQquONi0mgZS1naBqs1jtJf 2VQ3zMuWdTcK43ZZRRWUYYX2h1jcI47In3bm5lFlTsHBB42hEBUJcfRdi//Q91fr3x0Ll nqb7wSx2RWyGLk+R3pHQOcdlNl/3uGvKP5ksBAY02qnMjAHMoaS02pUynq/3MFAZsV3kV Fp1kc/mo1s3ivRivVkYo096hZ5CnwzXuF+WM+hN48Q1N07uKtCzKG8X8uPa9N6FONwvzK F2T3qHhxsmNdmQTIlDVirrhy3KXBQGcH4Mjh3r0mpeAadPttkS6fW5g0CO0jWEI= ARC-Message-Signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1772024979; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=Zt7RKiHU+N4gsCRwFu2kQi2hB4godiYmnjsKiBEsFl8=; b=Cw5cySwW/J4cxMbF2ByAiITItHvzIC5x6Fr5tkCSRz2SxieE9B6LmY7qpxtFXXeOtwSz o5OnJ9makcuMI4/GazM/lVG/gCfSfZtj3qGtmysmBSnOfFFtVyLO5ARMSyEDZ9nWH6407 ebG1+WttuMGh5Tm1khDgB5rzK11DZtB+EzkVA90FwOYjfzrt7GFAwcJHQeoY7ZTAoLglk CPxStZozoMkIu1RHoyfpmDn7fatOl/sQBSAcgWwzqEWsWDgTmViABfg1JMsgKBGGqcSLt 6c2zF7+WtkeKLeVHk96LLK8DL6glEAjOGPFxxFiu0REbvl/disiUPzy0EoCoo46OlpOP6 rDsITq3+yQMc44PHGdWFN2nFhbsEm69fBBPgffUYY5IraSh6wfW8Ek07sBrC/1y3VCVPQ 9hrHObiNLonu2LGc8k9RIwzhNXJVo6JZqcKMGjqiqmA+LngeuGz3uH1eXwlhkhX/yqISy Djya90a/4GXAc+/sbLLStKlNwmia7YXS7fd9/Ta4Bp45NIXPeb7gOSd61bsKCRGua4C6c ksQuulqRAMQeos+Sxnd5MQGJakFq2DSbSIpwOubSPqGeT6clHzGTvQ2kca/yzN4XApxWg BtB7zzPMOa3NCSribuHdjrywk66k98LqYkbPGexmeZukoccEVxsp4usFTDUlFpY= ARC-Authentication-Results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47 MIME-Version: 1.0 Date: Wed, 25 Feb 2026 14:09:39 +0100 From: Nicola Vetrini To: Andrew Cooper Cc: Roberto Bagnara , Xen-devel , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , "consulting @ bugseng . com" Subject: Re: [PATCH 09/12] x86/shadow: Rework write_atomic() call in shadow_write_entries() In-Reply-To: References: <20260220214653.3497384-1-andrew.cooper3@citrix.com> <20260220214653.3497384-10-andrew.cooper3@citrix.com> <0148ea9f-6486-44a1-b4dd-47af7c978351@bugseng.com> <278f711d-7c61-4a47-868e-ab05b9426e40@citrix.com> <678f1a67603d4b37d717dc84565db044@bugseng.com> Message-ID: <225c04a554ededd04fd6edacf34fd2c6@bugseng.com> X-Sender: nicola.vetrini@bugseng.com Organization: BUGSENG s.r.l. Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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