xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: [PATCH v2 4/4] xen/x86: Correct mandatory and SMP barrier definitions
Date: Wed, 16 Aug 2017 12:22:10 +0100	[thread overview]
Message-ID: <1502882530-31700-5-git-send-email-andrew.cooper3@citrix.com> (raw)
In-Reply-To: <1502882530-31700-1-git-send-email-andrew.cooper3@citrix.com>

Barriers are a complicated topic, a source of confusion, and their incorrect
use is a common cause of bugs.  It *really* doesn't help when Xen's API is the
same as Linux, but its ABI different.

Bring the two back in line, so programmers stand a chance of actually getting
their usage correct.

Drop the links in the comment, both of which are now stale.  Instead, refer to
the vendor system manuals.

No functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>

v2:
 * Keep mandatory barrier definitions
 * Drop stale documentation links
---
 xen/include/asm-x86/system.h        | 28 ++++++++++++++++------------
 xen/include/asm-x86/x86_64/system.h |  3 ---
 2 files changed, 16 insertions(+), 15 deletions(-)

diff --git a/xen/include/asm-x86/system.h b/xen/include/asm-x86/system.h
index 9cb6fd7..3d21291 100644
--- a/xen/include/asm-x86/system.h
+++ b/xen/include/asm-x86/system.h
@@ -164,23 +164,27 @@ static always_inline unsigned long __xadd(
     ((typeof(*(ptr)))__xadd(ptr, (typeof(*(ptr)))(v), sizeof(*(ptr))))
 
 /*
+ * Mandatory barriers, for enforced ordering of reads and writes, e.g. for use
+ * with MMIO devices mapped with reduced cacheability.
+ */
+#define mb()            asm volatile ("mfence" ::: "memory")
+#define rmb()           asm volatile ("lfence" ::: "memory")
+#define wmb()           asm volatile ("sfence" ::: "memory")
+
+/*
+ * SMP barriers, for ordering of reads and writes between CPUs, most commonly
+ * used with shared memory.
+ *
  * Both Intel and AMD agree that, from a programmer's viewpoint:
  *  Loads cannot be reordered relative to other loads.
  *  Stores cannot be reordered relative to other stores.
- * 
- * Intel64 Architecture Memory Ordering White Paper
- * <http://developer.intel.com/products/processor/manuals/318147.pdf>
- * 
- * AMD64 Architecture Programmer's Manual, Volume 2: System Programming
- * <http://www.amd.com/us-en/assets/content_type/\
- *  white_papers_and_tech_docs/24593.pdf>
+ *  Loads may be reordered ahead of an unaliasing store.
+ *
+ * Refer to the vendor system programming manuals for further details.
  */
-#define rmb()           barrier()
-#define wmb()           barrier()
-
 #define smp_mb()        mb()
-#define smp_rmb()       rmb()
-#define smp_wmb()       wmb()
+#define smp_rmb()       barrier()
+#define smp_wmb()       barrier()
 
 #define set_mb(var, value) do { xchg(&var, value); } while (0)
 #define set_wmb(var, value) do { var = value; smp_wmb(); } while (0)
diff --git a/xen/include/asm-x86/x86_64/system.h b/xen/include/asm-x86/x86_64/system.h
index 88beae1..6b56761 100644
--- a/xen/include/asm-x86/x86_64/system.h
+++ b/xen/include/asm-x86/x86_64/system.h
@@ -80,7 +80,4 @@ static always_inline __uint128_t __cmpxchg16b(
     _rc;                                                                \
 })
 
-#define mb()                    \
-    asm volatile ( "mfence" : : : "memory" )
-
 #endif /* __X86_64_SYSTEM_H__ */
-- 
2.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  parent reply	other threads:[~2017-08-16 11:22 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-16 11:22 [PATCH v2 0/4] x86: Corrections to barrier usage Andrew Cooper
2017-08-16 11:22 ` [PATCH v2 1/4] x86/mcheck: Minor cleanup to amd_nonfatal Andrew Cooper
2017-08-16 15:11   ` Jan Beulich
2017-08-18 13:19   ` Tim Deegan
2017-08-16 11:22 ` [PATCH v2 2/4] xen/x86: Drop unnecessary barriers Andrew Cooper
2017-08-16 15:23   ` Jan Beulich
2017-08-16 16:47     ` Andrew Cooper
2017-08-16 17:03       ` Andrew Cooper
2017-08-17  7:50         ` Jan Beulich
2017-08-17  7:48       ` Jan Beulich
2017-08-18 14:47         ` Tim Deegan
2017-08-18 15:04           ` Jan Beulich
2017-08-18 15:13             ` Tim Deegan
2017-08-18 15:07           ` Tim Deegan
2017-08-16 17:18   ` [PATCH v2 2.5/4] xen/x86: Replace mandatory barriers with compiler barriers Andrew Cooper
2017-08-17  8:15     ` Jan Beulich
2017-08-18 13:55   ` [PATCH v2 2/4] xen/x86: Drop unnecessary barriers Tim Deegan
2017-08-18 14:07     ` Tim Deegan
2017-08-18 14:23     ` [PATCH] xen/x86/shadow: adjust barriers around gtable_dirty_version Tim Deegan
2017-08-18 14:26       ` Andrew Cooper
2017-08-16 11:22 ` [PATCH v2 3/4] xen/x86: Replace remaining mandatory barriers with SMP barriers Andrew Cooper
2017-08-16 15:42   ` Dario Faggioli
2017-08-17  8:37   ` Jan Beulich
2017-08-17  9:35     ` Andrew Cooper
2017-08-17 10:01       ` Jan Beulich
2017-08-16 11:22 ` Andrew Cooper [this message]
2017-08-16 15:44   ` [PATCH v2 4/4] xen/x86: Correct mandatory and SMP barrier definitions Dario Faggioli
2017-08-17  8:41   ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1502882530-31700-5-git-send-email-andrew.cooper3@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).