From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH for 4.6 03/13] xen: Introduce ACCESS_ONCE macro Date: Wed, 17 Dec 2014 12:54:52 +0000 Message-ID: <54917D1C.3080908@linaro.org> References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org> <1418760534-18163-4-git-send-email-julien.grall@linaro.org> <5491636F020000780005027B@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Y1E8E-0005im-N8 for xen-devel@lists.xenproject.org; Wed, 17 Dec 2014 12:55:10 +0000 Received: by mail-wg0-f41.google.com with SMTP id y19so20273015wgg.0 for ; Wed, 17 Dec 2014 04:55:09 -0800 (PST) In-Reply-To: <5491636F020000780005027B@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Keir Fraser , ian.campbell@citrix.com, tim@xen.org, manish.jaggi@caviumnetworks.com, Ian Jackson , stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org Hi Jan, On 17/12/14 10:05, Jan Beulich wrote: >>>> On 16.12.14 at 21:08, wrote: >> --- a/xen/include/xen/compiler.h >> +++ b/xen/include/xen/compiler.h >> @@ -90,4 +90,18 @@ >> __asm__ ("" : "=r"(__ptr) : "0"(ptr)); \ >> (typeof(ptr)) (__ptr + (off)); }) >> >> +/* >> + * Prevent the compiler from merging or refetching accesses. The compiler >> + * is also forbidden from reordering successive instances of ACCESS_ONCE(), >> + * but only when the compiler is aware of some particular ordering. One way >> + * to make the compiler aware of ordering is to put the two invocations of >> + * ACCESS_ONCE() in different C statements. >> + * >> + * This macro does absolutely -nothing- to prevent the CPU from reordering, >> + * merging, or refetching absolutely anything at any time. Its main intended >> + * use is to mediate communication between process-level code and irq/NMI >> + * handlers, all running on the same CPU. >> + */ >> +#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x)) > > Any reason not to simply use {read,write}_atomic() instead, which we > already have? To avoid modifying Linux drivers when it's not necessary and doesn't harm. Regards, -- Julien Grall