We're having a hard time tracking down a PowerPC bug that seems to be
related to KVM's signal handling (SIGALRM in particular), so we're
trying to understand the overall signal handling design.
It looks like the run sequence goes something like this:
1. qemu: block SIGALRM (and a couple others)
2. qemu: call kvm_run
3. kvm: unblocks SIGALRM
4. kvm: executes guest
5. kvm: exit handler checks signal_pending(); if true returns to
qemu
6. kvm: re-blocks SIGALRM and returns to qemu
7. qemu: kvm_eat_signals() synchronously calls the normal handlers
for blocked signals
I'm confused about a few things. First, why must qemu unblock these
signals? AFAICS signal_pending() still returns true regardless of the
process's signal mask.
Second, why are we synchronously calling the signal handlers in the
first place? Why not allow the signals simply to be delivered?
--
Hollis Blanchard
IBM Linux Technology Center
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
