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+n8rbub2vvmrm7lct0mugm...@mail.gmail.com Signed-off-by: Akihiko Odaki <akihiko.od...@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-5b784cc8e...@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-f7f69247d...@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-7953177ce...@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-a58c8d63e...@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.od...@daynix.com>
