On 2025/05/27 22:46, Peter Xu wrote:
On Tue, May 27, 2025 at 11:09:08AM +0900, Akihiko Odaki wrote:
On 2025/05/26 23:48, Peter Xu wrote:
On Mon, May 26, 2025 at 02:29:10PM +0900, Akihiko Odaki wrote:
Akihiko Odaki (11):
futex: Check value after qemu_futex_wait()
futex: Support Windows
qemu-thread: Remove qatomic_read() in qemu_event_set()
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
In case it makes things easier.. I queued the three migration patches;
AFAIU they look like standalone to go even without prior patches, meanwhile
it shouldn't be an issue if they're queued in two pulls.
I am still not sure whether patch 1 is needed at all, but I'll leave that
to others to decide.
The migration patches shouldn't be applied before patches "futex: Check
value after qemu_futex_wait()" and "qemu-thread: Avoid futex abstraction for
non-Linux" as they fix QemuEvent. Merging migration patches earlier can
trigger bugs just like one we faced with hw/display/apple-gfx*
I didn't see anything like it mentioned in either cover letter or the
apple-gfx patch. Could you provide a pointer?
The previous email had a URL at the bottom:
https://lore.kernel.org/qemu-devel/a8b4472c-8741-4f80-87e5-b406c56d1...@daynix.com/
This thread discussed a bug of QemuEvent and reached to a conclusion to
use QemuSemaphore instead to avoid it. This patch series intends to fix it.
Regards,
Akihiko Odaki
