In a recent discussion, Phil Dennis-Jordan pointed out a quirk in
QemuEvent destruction due to futex-like abstraction, which prevented
the usage of QemuEvent in new and existing code[1]. With some more
thoughts after this discussion, I also found other problem and room
of improvement in futex usage. Here is a stack of patches to resolve
them.
Patch "futex: Check value after qemu_futex_wait()" ensures
qemu_futex_wait() is used in loops as suggested in the man page.
Patch "futex: Support Windows" implements futex functions for Windows.
Patch "qemu-thread: Avoid futex abstraction for non-Linux" and
"qemu-thread: Use futex for QemuEvent on Windows" enable destroying
QemuEvent immediately after qemu_event_wait().
Patch "qemu-thread: Use futex for QemuEvent on Windows" and
"qemu-thread: Use futex if available for QemuLockCnt" make the use of
futex functions added for Windows.
Patches "migration: Replace QemuSemaphore with QemuEvent",
"migration/colo: Replace QemuSemaphore with QemuEvent",
"migration/postcopy: Replace QemuSemaphore with QemuEvent", and
"hw/display/apple-gfx: Replace QemuSemaphore with QemuEvent" replace
some QemuSemaphores with QemuEvents, which can utilize futex. Some of
them rely on that QemuEvent can be destroyed immediately after
qemu_event_wait().
[1]: https://lore.kernel.org/r/CAAibmn3HZeDeK8FrYhHa1GGwc+N8rBuB2VvMRm7LCt0mUGmsYQ@mail.gmail.com
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
---
Changes in v5:
- Updated the documentation of the state transitions for the non-futex
variant.
- Placed patch "qemu-thread: Remove qatomic_read() in qemu_event_set()"
after all other code changes.
- Added patches "qemu-thread: Document QemuEvent" and
"qemu-thread: Document QemuEvent memory ordering".
- Link to v4: https://lore.kernel.org/qemu-devel/20250526-event-v4-0-5b784cc8e1de@daynix.com
Changes in v4:
- Added patch "qemu-thread: Remove qatomic_read() in qemu_event_set()".
- Renamed patch "futex: Replace __linux__ with CONFIG_LINUX" to
"qemu-thread: Replace __linux__ with CONFIG_LINUX".
- Reverted changes to convert rp_pong_acks to QemuEvent.
- Link to v3: https://lore.kernel.org/qemu-devel/20250511-event-v3-0-f7f69247d303@daynix.com
Changes in v3:
- Fixed race between qemu_event_reset() and qemu_event_set().
- Prepared for spurious pthread_cond_wait() wakeups.
- Added patch "futex: Replace __linux__ with CONFIG_LINUX".
- Link to v2: https://lore.kernel.org/qemu-devel/20250510-event-v2-0-7953177ce1b8@daynix.com
Changes in v2:
- Rebased.
- Added patch
"hw/display/apple-gfx: Replace QemuSemaphore with QemuEvent".
- Link to v1: https://lore.kernel.org/r/20241225-event-v1-0-a58c8d63eb70@daynix.com
---
Akihiko Odaki (13):
futex: Check value after qemu_futex_wait()
futex: Support Windows
qemu-thread: Replace __linux__ with CONFIG_LINUX
qemu-thread: Avoid futex abstraction for non-Linux
qemu-thread: Use futex for QemuEvent on Windows
qemu-thread: Use futex if available for QemuLockCnt
migration: Replace QemuSemaphore with QemuEvent
migration/colo: Replace QemuSemaphore with QemuEvent
migration/postcopy: Replace QemuSemaphore with QemuEvent
hw/display/apple-gfx: Replace QemuSemaphore with QemuEvent
qemu-thread: Remove qatomic_read() in qemu_event_set()
qemu-thread: Document QemuEvent
qemu-thread: Document QemuEvent memory ordering
meson.build | 2 +
include/qemu/futex.h | 44 +++++++++++-
include/qemu/lockcnt.h | 2 +-
include/qemu/thread-posix.h | 9 ---
include/qemu/thread-win32.h | 6 --
include/qemu/thread.h | 40 ++++++++++-
migration/migration.h | 12 ++--
migration/colo.c | 20 +++---
migration/migration.c | 21 +++---
migration/postcopy-ram.c | 10 +--
migration/savevm.c | 2 +-
tests/unit/test-aio-multithread.c | 6 +-
util/event.c | 139 +++++++++++++++++++++++++++++++++++
util/lockcnt.c | 9 +--
util/qemu-thread-posix.c | 148 --------------------------------------
util/qemu-thread-win32.c | 129 ---------------------------------
hw/display/apple-gfx.m | 10 +--
util/meson.build | 3 +-
18 files changed, 269 insertions(+), 343 deletions(-)
---
base-commit: f0737158b483e7ec2b2512145aeab888b85cc1f7
change-id: 20241031-event-785a2f0dda4a
Best regards,
--
Akihiko Odaki <akihiko.odaki@daynix.com>