]> git.ipfire.org Git - thirdparty/open-vm-tools.git/commitdiff
Changes to common header files not applicable to open-vm-tools.
authorJohn Wolfe <jwolfe@vmware.com>
Tue, 19 Apr 2022 21:30:54 +0000 (14:30 -0700)
committerJohn Wolfe <jwolfe@vmware.com>
Tue, 19 Apr 2022 21:30:54 +0000 (14:30 -0700)
open-vm-tools/lib/include/vm_basic_asm.h
open-vm-tools/lib/include/vm_basic_asm_arm64.h
open-vm-tools/lib/include/vm_basic_asm_x86_common.h

index f76b516a29ff03ee843bf3faf308a6e4ea20d36e..b8119fe658af8a47c8fdfbc7265a4ab025f900bd 100644 (file)
@@ -1289,7 +1289,7 @@ PopCount64(uint64 value)
  *      Enforce ordering on memory operations witnessed by and
  *      affected by interrupt handlers.
  *
- *      This should be used to replace the legacy COMPILER_*_BARRIER
+ *      This should be used to replace the legacy COMPILER_MEM_BARRIER
  *      for code that has been audited to determine it only needs
  *      ordering with respect to interrupt handlers, and not to other
  *      CPUs (SMP_*), memory-mapped I/O (MMIO_*), or DMA (DMA_*).
index ae59511d454a750a5fc1ef6308bc70cc1cb6fedc..6f915190778b9597ae0fba3d88703a179b542e98 100644 (file)
@@ -1,5 +1,5 @@
 /*********************************************************
- * Copyright (C) 2013-2021 VMware, Inc. All rights reserved.
+ * Copyright (C) 2013-2022 VMware, Inc. All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms of the GNU Lesser General Public License as published
@@ -202,34 +202,33 @@ ESB(void)
  *    Semantics
  *    ---------
  *
- * At the time COMPILER_*_BARRIER were created (and references to them were
+ * At the time COMPILER_MEM_BARRIER was created (and references to it were
  * added to the code), the code was only targetting x86. The intent of the code
  * was really to use a memory barrier, but because x86 uses a strongly ordered
- * memory model, the CPU would not re-order memory accesses, and the code could
- * get away with using just a compiler memory barrier. So COMPILER_*_BARRIER
- * were born and were implemented as compiler memory barriers _on x86_. But
- * make no mistake, _the semantics that the code expects from
- * COMPILER_*_BARRIER are that of a memory barrier_!
+ * memory model, the CPU would not re-order most memory accesses (store-load
+ * ordering still requires MFENCE even on x86), and the code could get away
+ * with using just a compiler memory barrier. So COMPILER_MEM_BARRIER was born
+ * and was implemented as a compiler memory barrier _on x86_. But make no
+ * mistake, _the semantics that the code expects from COMPILER_MEM_BARRIER is
+ * that of a memory barrier_!
  *
  *    DO NOT USE!
  *    -----------
  *
- * On at least one non-x86 architecture, COMPILER_*_BARRIER are
- * 1) Misnomers
+ * On at least one non-x86 architecture, COMPILER_MEM_BARRIER is
+ * 1) A misnomer
  * 2) Not fine-grained enough to provide the best performance.
- * For the above two reasons, usage of COMPILER_*_BARRIER is now deprecated.
- * _Do not add new references to COMPILER_*_BARRIER._ Instead, precisely
+ * For the above two reasons, usage of COMPILER_MEM_BARRIER is now deprecated.
+ * _Do not add new references to COMPILER_MEM_BARRIER._ Instead, precisely
  * document the intent of your code by using
  * <mem_type/purpose>_<before_access_type>_BARRIER_<after_access_type>.
- * Existing references to COMPILER_*_BARRIER are being slowly but surely
- * converted, and when no references are left, COMPILER_*_BARRIER will be
+ * Existing references to COMPILER_MEM_BARRIER are being slowly but surely
+ * converted, and when no references are left, COMPILER_MEM_BARRIER will be
  * retired.
  *
  * Thanks for pasting this whole comment into every architecture header.
  */
 
-#define COMPILER_READ_BARRIER()  SMP_R_BARRIER_R()
-#define COMPILER_WRITE_BARRIER() SMP_W_BARRIER_W()
 #define COMPILER_MEM_BARRIER()   SMP_RW_BARRIER_RW()
 
 /*
index ed64082167b5aa47d14935122bc508a7418a2b6d..8fd5290e023e52751eca49394c25e4859b356090 100644 (file)
@@ -1,5 +1,5 @@
 /*********************************************************
- * Copyright (C) 2013-2021 VMware, Inc. All rights reserved.
+ * Copyright (C) 2013-2022 VMware, Inc. All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms of the GNU Lesser General Public License as published
@@ -431,39 +431,36 @@ LOCKED_INSN_BARRIER(void)
  *    Semantics
  *    ---------
  *
- * At the time COMPILER_*_BARRIER were created (and references to them were
+ * At the time COMPILER_MEM_BARRIER was created (and references to it were
  * added to the code), the code was only targetting x86. The intent of the code
  * was really to use a memory barrier, but because x86 uses a strongly ordered
- * memory model, the CPU would not re-order memory accesses, and the code could
- * get away with using just a compiler memory barrier. So COMPILER_*_BARRIER
- * were born and were implemented as compiler memory barriers _on x86_. But
- * make no mistake, _the semantics that the code expects from
- * COMPILER_*_BARRIER are that of a memory barrier_!
+ * memory model, the CPU would not re-order most memory accesses (store-load
+ * ordering still requires MFENCE even on x86), and the code could get away
+ * with using just a compiler memory barrier. So COMPILER_MEM_BARRIER was born
+ * and was implemented as a compiler memory barrier _on x86_. But make no
+ * mistake, _the semantics that the code expects from COMPILER_MEM_BARRIER is
+ * that of a memory barrier_!
  *
  *    DO NOT USE!
  *    -----------
  *
- * On at least one non-x86 architecture, COMPILER_*_BARRIER are
- * 1) Misnomers
+ * On at least one non-x86 architecture, COMPILER_MEM_BARRIER is
+ * 1) A misnomer
  * 2) Not fine-grained enough to provide the best performance.
- * For the above two reasons, usage of COMPILER_*_BARRIER is now deprecated.
- * _Do not add new references to COMPILER_*_BARRIER._ Instead, precisely
+ * For the above two reasons, usage of COMPILER_MEM_BARRIER is now deprecated.
+ * _Do not add new references to COMPILER_MEM_BARRIER._ Instead, precisely
  * document the intent of your code by using
  * <mem_type/purpose>_<before_access_type>_BARRIER_<after_access_type>.
- * Existing references to COMPILER_*_BARRIER are being slowly but surely
- * converted, and when no references are left, COMPILER_*_BARRIER will be
+ * Existing references to COMPILER_MEM_BARRIER are being slowly but surely
+ * converted, and when no references are left, COMPILER_MEM_BARRIER will be
  * retired.
  *
  * Thanks for pasting this whole comment into every architecture header.
  */
 
 #if defined __GNUC__
-#   define COMPILER_READ_BARRIER()  COMPILER_MEM_BARRIER()
-#   define COMPILER_WRITE_BARRIER() COMPILER_MEM_BARRIER()
 #   define COMPILER_MEM_BARRIER()   __asm__ __volatile__("" ::: "memory")
 #elif defined _MSC_VER
-#   define COMPILER_READ_BARRIER()  _ReadBarrier()
-#   define COMPILER_WRITE_BARRIER() _WriteBarrier()
 #   define COMPILER_MEM_BARRIER()   _ReadWriteBarrier()
 #endif
 
@@ -528,7 +525,7 @@ LOCKED_INSN_BARRIER(void)
  * i.e. WB using above terminology), so we only need to worry about store-load
  * reordering. In other cases a compiler barrier is sufficient. SMP store-load
  * reordering is handled with a locked XOR (instead of a proper MFENCE
- * instructon) for performance reasons. See PR 1674199 for more details.
+ * instruction) for performance reasons. See PR 1674199 for more details.
  *
  * DMA barriers are equivalent to SMP barriers on x86.
  *
@@ -538,11 +535,11 @@ LOCKED_INSN_BARRIER(void)
  * not guarding non-temporal/WC accesses.
  */
 
-#define SMP_R_BARRIER_R()     COMPILER_READ_BARRIER()
+#define SMP_R_BARRIER_R()     INTR_R_BARRIER_R()
 #define SMP_R_BARRIER_W()     COMPILER_MEM_BARRIER()
 #define SMP_R_BARRIER_RW()    COMPILER_MEM_BARRIER()
 #define SMP_W_BARRIER_R()     LOCKED_INSN_BARRIER()
-#define SMP_W_BARRIER_W()     COMPILER_WRITE_BARRIER()
+#define SMP_W_BARRIER_W()     INTR_W_BARRIER_W()
 #define SMP_W_BARRIER_RW()    LOCKED_INSN_BARRIER()
 #define SMP_RW_BARRIER_R()    LOCKED_INSN_BARRIER()
 #define SMP_RW_BARRIER_W()    COMPILER_MEM_BARRIER()