On 08.05.2012 23:35, Jan Kiszka wrote: > Hi, > > I hunted down a fairly subtle corruption of the VCPU thread signal mask > in KVM mode when using the ucontext version of coroutines: > > coroutine_new calls getcontext, makecontext, swapcontext. Those > functions get/set also the signal mask of the caller. Unfortunately, > they only use the sigprocmask syscall on i386, not the rt_sigprocmask > version. So they do not properly save/restore the blocked RT signals, > namely our SIG_IPI - it becomes unblocke this way. And this will sooner > or later make the kernel actually deliver a SIG_IPI to our > dummy_handler, and we miss a wakeup, which means losing control over > VCPU thread - qemu hangs. > > I was able to reproduce the issue very reliably with virtio-block > enabled, 32-bit qemu userspace on a 64-bit host, using a 32-bit WinXP > guest. > > Simple workaround: > > diff --git a/main-loop.h b/main-loop.h > index c06b8bc..dce1cd9 100644 > --- a/main-loop.h > +++ b/main-loop.h > @@ -25,11 +25,7 @@ > #ifndef QEMU_MAIN_LOOP_H > #define QEMU_MAIN_LOOP_H 1 > > -#ifdef SIGRTMIN > -#define SIG_IPI (SIGRTMIN+4) > -#else > #define SIG_IPI SIGUSR1 > -#endif [] > Michael, maybe this also relates to the issue you saw. I'm not able to > reproduce any VAPIC problems after make Windows bootable by switching > to SIGUSR1.
FWIW, this fixes both the STOP 0x5c during reboot of windows 32bit guest and my other issue, with qemu stalling on 32/64bit environment. So yes indeed, that's the same thing apparently... Nice catch! /mjt
