diff options
| -rw-r--r-- | docs/devel/atomics.rst | 20 | ||||
| -rw-r--r-- | hw/intc/ioapic.c | 3 | ||||
| -rw-r--r-- | softmmu/vl.c | 9 | ||||
| -rw-r--r-- | target/i386/kvm/kvm.c | 2 |
4 files changed, 21 insertions, 13 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) | diff --git a/hw/intc/ioapic.c b/hw/intc/ioapic.c index 6364ecab1b..716ffc8bbb 100644 --- a/hw/intc/ioapic.c +++ b/hw/intc/ioapic.c @@ -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 = { diff --git a/softmmu/vl.c b/softmmu/vl.c index 3340f63c37..ea20b23e4c 100644 --- a/softmmu/vl.c +++ b/softmmu/vl.c @@ -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) { diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c index 1aef54f87e..de531842f6 100644 --- a/target/i386/kvm/kvm.c +++ b/target/i386/kvm/kvm.c @@ -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. */ |