RE: Adopting the Linux Kernel Memory Model in Xen?

From: Paul Durrant <xadimgnik@gmail.com>
To: "'Julien Grall'" <julien@xen.org>,
	<xen-devel@lists.xenproject.org>, <committers@xenproject.org>
Cc: "'Roger Pau Monné'" <roger.pau@citrix.com>,
	"'Bertrand Marquis'" <Bertrand.Marquis@arm.com>
Subject: RE: Adopting the Linux Kernel Memory Model in Xen?
Date: Mon, 14 Sep 2020 07:59:37 +0100	[thread overview]
Message-ID: <000101d68a64$9c7ba580$d572f080$@xen.org> (raw)
In-Reply-To: <1bc70974-2efb-2e73-34bf-bdd3c1d0ef96@xen.org>

> -----Original Message-----
> From: Xen-devel <xen-devel-bounces@lists.xenproject.org> On Behalf Of Julien Grall
> Sent: 11 September 2020 17:34
> To: xen-devel@lists.xenproject.org; committers@xenproject.org
> Cc: Roger Pau Monné <roger.pau@citrix.com>; Bertrand Marquis <Bertrand.Marquis@arm.com>
> Subject: Adopting the Linux Kernel Memory Model in Xen?
> 
> Hi all,
> 
> At the moment, Xen doesn't have a formal memory model. Instead, we are
> relying on intuitions. This can lead to heated discussion on what can a
> processor/compiler do or not.
> 

...which, in turn, may well lead us into decisions that harm performance.

> We also have some helpers that nearly do the same (such as
> {read,write}_atomic() vs ACCESS_ONCE()) with no clear understanding
> where to use which.
> 
> In the past few years, Linux community spent a lot of time to write down
> their memory model and make the compiler communities aware of it (see
> [1], [2]).
> 
> There are a few reasons I can see for adopting LKMM:
>     - Xen borrows a fair amount of code from Linux;

...and essentially the same toolchain(s)

>     - There are efforts to standardize it;
>     - This will allow us to streamline the discussion.
> 
> Any thoughts?
> 

It seems like a very good idea to me.

  Paul

> Cheers,
> 
> [1] https://www.kernel.org/doc/Documentation/memory-barriers.txt
> [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0124r7.html
> 
> 
> --
> Julien Grall