diff options
| -rw-r--r-- | docs/devel/atomics.rst | 20 | ||||
| -rw-r--r-- | hw/input/ps2.c | 6 | ||||
| -rw-r--r-- | hw/intc/ioapic.c | 3 | ||||
| -rw-r--r-- | io/channel-tls.c | 1 | ||||
| -rw-r--r-- | qapi/ui.json | 15 | ||||
| -rw-r--r-- | softmmu/vl.c | 9 | ||||
| -rw-r--r-- | target/i386/kvm/kvm.c | 2 | ||||
| m--------- | ui/keycodemapdb | 0 |
8 files changed, 42 insertions, 14 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/input/ps2.c b/hw/input/ps2.c index 3253ab6a92..45af76a837 100644 --- a/hw/input/ps2.c +++ b/hw/input/ps2.c @@ -402,6 +402,9 @@ static void ps2_keyboard_event(DeviceState *dev, QemuConsole *src, ps2_put_keycode(s, 0xaa); } } + } else if ((qcode == Q_KEY_CODE_LANG1 || qcode == Q_KEY_CODE_LANG2) + && !key->down) { + /* Ignore release for these keys */ } else { if (qcode < qemu_input_map_qcode_to_atset1_len) { keycode = qemu_input_map_qcode_to_atset1[qcode]; @@ -497,6 +500,9 @@ static void ps2_keyboard_event(DeviceState *dev, QemuConsole *src, ps2_put_keycode(s, 0x12); } } + } else if ((qcode == Q_KEY_CODE_LANG1 || qcode == Q_KEY_CODE_LANG2) && + !key->down) { + /* Ignore release for these keys */ } else { if (qcode < qemu_input_map_qcode_to_atset2_len) { keycode = qemu_input_map_qcode_to_atset2[qcode]; 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/io/channel-tls.c b/io/channel-tls.c index 8052945ba0..5a7a3d48d6 100644 --- a/io/channel-tls.c +++ b/io/channel-tls.c @@ -446,6 +446,7 @@ qio_channel_tls_read_watch(QIOChannelTLS *tioc, GSource *source) object_ref(OBJECT(tioc)); g_source_add_child_source(source, child); + g_source_unref(child); } static GSource *qio_channel_tls_create_watch(QIOChannel *ioc, diff --git a/qapi/ui.json b/qapi/ui.json index 0abba3e930..98322342f7 100644 --- a/qapi/ui.json +++ b/qapi/ui.json @@ -886,6 +886,19 @@ # @lang1: since 6.1 # @lang2: since 6.1 # +# @f13: since 8.0 +# @f14: since 8.0 +# @f15: since 8.0 +# @f16: since 8.0 +# @f17: since 8.0 +# @f18: since 8.0 +# @f19: since 8.0 +# @f20: since 8.0 +# @f21: since 8.0 +# @f22: since 8.0 +# @f23: since 8.0 +# @f24: since 8.0 +# # 'sysrq' was mistakenly added to hack around the fact that # the ps2 driver was not generating correct scancodes sequences # when 'alt+print' was pressed. This flaw is now fixed and the @@ -918,7 +931,7 @@ 'volumeup', 'volumedown', 'mediaselect', 'mail', 'calculator', 'computer', 'ac_home', 'ac_back', 'ac_forward', 'ac_refresh', 'ac_bookmarks', - 'lang1', 'lang2' ] } + 'lang1', 'lang2','f13','f14','f15','f16','f17','f18','f19','f20','f21','f22','f23','f24' ] } ## # @KeyValueKind: 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. */ diff --git a/ui/keycodemapdb b/ui/keycodemapdb -Subproject d21009b1c9f94b740ea66be8e48a1d8ad812402 +Subproject f5772a62ec52591ff6870b7e8ef32482371f22c |