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----- 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>
This commit is contained in:
commit
be4033d76e
@ -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.
|
||||
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.
|
||||
|
||||
- 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:
|
||||
- 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) |
|
||||
|
@ -405,6 +405,7 @@ ioapic_mem_write(void *opaque, hwaddr addr, uint64_t val,
|
||||
s->ioredtbl[index] |= ro_bits;
|
||||
s->irq_eoi[index] = 0;
|
||||
ioapic_fix_edge_remote_irr(&s->ioredtbl[index]);
|
||||
ioapic_update_kvm_routes(s);
|
||||
ioapic_service(s);
|
||||
}
|
||||
}
|
||||
@ -417,8 +418,6 @@ ioapic_mem_write(void *opaque, hwaddr addr, uint64_t val,
|
||||
ioapic_eoi_broadcast(val);
|
||||
break;
|
||||
}
|
||||
|
||||
ioapic_update_kvm_routes(s);
|
||||
}
|
||||
|
||||
static const MemoryRegionOps ioapic_io_ops = {
|
||||
|
@ -2465,10 +2465,11 @@ static void qemu_maybe_daemonize(const char *pid_file)
|
||||
|
||||
pid_file_realpath = g_malloc0(PATH_MAX);
|
||||
if (!realpath(pid_file, pid_file_realpath)) {
|
||||
error_report("cannot resolve PID file path: %s: %s",
|
||||
pid_file, strerror(errno));
|
||||
unlink(pid_file);
|
||||
exit(1);
|
||||
if (errno != ENOENT) {
|
||||
warn_report("not removing PID file on exit: cannot resolve PID "
|
||||
"file path: %s: %s", pid_file, strerror(errno));
|
||||
}
|
||||
return;
|
||||
}
|
||||
|
||||
qemu_unlink_pidfile_notifier = (struct UnlinkPidfileNotifier) {
|
||||
|
@ -4991,6 +4991,7 @@ MemTxAttrs kvm_arch_post_run(CPUState *cpu, struct kvm_run *run)
|
||||
kvm_rate_limit_on_bus_lock();
|
||||
}
|
||||
|
||||
#ifdef CONFIG_XEN_EMU
|
||||
/*
|
||||
* If the callback is asserted as a GSI (or PCI INTx) then check if
|
||||
* vcpu_info->evtchn_upcall_pending has been cleared, and deassert
|
||||
@ -5001,6 +5002,7 @@ MemTxAttrs kvm_arch_post_run(CPUState *cpu, struct kvm_run *run)
|
||||
if (x86_cpu->env.xen_callback_asserted) {
|
||||
kvm_xen_maybe_deassert_callback(cpu);
|
||||
}
|
||||
#endif
|
||||
|
||||
/* We need to protect the apic state against concurrent accesses from
|
||||
* different threads in case the userspace irqchip is used. */
|
||||
|
Loading…
Reference in New Issue
Block a user