KVM's signal masking
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?
Signature · 8 lines
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/
Quoted 4 lines · Hollis Blanchard
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.
Quoted 12 lines
It looks like the run sequence goes something like this:
1. qemu: block SIGALRM (and a couple others)
2. qemu: callkvm_run
3. kvm: unblocks SIGALRM
4. kvm: executes guest
5. kvm: exit handler checkssignal_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
Yes.
Quoted 4 lines
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.
You mean kvm unblocks. If the signals are blocked, the kernel will not wake up a sleeping process (or IPI a running one), resulting in unbounded latency.
Quoted 3 lines
Second, why are we synchronously calling the signal handlers in the first place? Why not allow the signals simply to be delivered?
Async signal delivery is slow and racy (can happen between any two instructions, without locking).
Ideally, we wouldn't dispatch the signals at all; dequeing a signal means "go check if something happened via select() or aio completion". I hadn't checked that all signal handlers are safe to omit, hence the call.
Signature · 7 lines
Do not meddle in the internals of kernels, for they are subtle and quick to panic. ------------------------------------------------------------------------- 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/