Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into staging

small bug fixes

# -----BEGIN PGP SIGNATURE-----
#
# iQFIBAABCAAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAmQRo3EUHHBib256aW5p
# QHJlZGhhdC5jb20ACgkQv/vSX3jHroO7wwgAp2IGW9TDAElFgPZ3n8XyoJ6Lnr6i
# Le3L+fQbYuy6uCU7zkboWgFqqNRLkd1nxHPkRgxb5oJ8pnXLCrdG+2d9UDgfMFqZ
# 3ankE+De70j7f7r0M5Ifmfyf7QHhNhnbuguoovi6S9bdJ5aO2nZmsm/T41Bth/uU
# SKx+SCVMzpPGLJv0iZishw2seZj0h9QBgyitsE8MdLjnhe5KD4XOWs4+E263pb6L
# G6ai7T++vQSRqCQ8YVBr7Az41vkvzuqkybAXFTl/QLd2rVQROAqoOpn+wPq4cH46
# xf6LscXqE9lrWr/UJnDPNiyKmsY5baLyB6Ri/rQn8VvTyfyHC9JtDoDclQ==
# =mnvI
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 15 Mar 2023 10:52:33 GMT
# gpg:                using RSA key F13338574B662389866C7682BFFBD25F78C7AE83
# gpg:                issuer "pbonzini@redhat.com"
# gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [full]
# gpg:                 aka "Paolo Bonzini <pbonzini@redhat.com>" [full]
# Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4  E2F7 7E15 100C CD36 69B1
#      Subkey fingerprint: F133 3857 4B66 2389 866C  7682 BFFB D25F 78C7 AE83

* tag 'for-upstream' of https://gitlab.com/bonzini/qemu:
  vl: defuse PID file path resolve error
  hw/intc/ioapic: Update KVM routes before redelivering IRQ, on RTE update
  docs/devel: clarify further the semantics of RMW operations
  Fix build without CONFIG_XEN_EMU

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

1 files changed, 13 insertions, 7 deletions

diff --git a/docs/devel/atomics.rst b/docs/devel/atomics.rst
index 633df65a97..81ec26be17 100644
--- a/docs/devel/atomics.rst
+++ b/docs/devel/atomics.rst
@@ -469,13 +469,19 @@ and memory barriers, and the equivalents in QEMU:
   In QEMU, the second kind is named ``atomic_OP_fetch``.
 
 - different atomic read-modify-write operations in Linux imply
-  a different set of memory barriers; in QEMU, all of them enforce
-  sequential consistency.
-
-- in QEMU, ``qatomic_read()`` and ``qatomic_set()`` do not participate in
-  the ordering enforced by read-modify-write operations.
-  This is because QEMU uses the C11 memory model.  The following example
-  is correct in Linux but not in QEMU:
+  a different set of memory barriers. In QEMU, all of them enforce
+  sequential consistency: there is a single order in which the
+  program sees them happen.
+
+- however, according to the C11 memory model that QEMU uses, this order
+  does not propagate to other memory accesses on either side of the
+  read-modify-write operation.  As far as those are concerned, the
+  operation consist of just a load-acquire followed by a store-release.
+  Stores that precede the RMW operation, and loads that follow it, can
+  still be reordered and will happen *in the middle* of the read-modify-write
+  operation!
+
+  Therefore, the following example is correct in Linux but not in QEMU:
 
       +----------------------------------+--------------------------------+
       | Linux (correct)                  | QEMU (incorrect)               |