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
next prev 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).