Re: [kvm-ppc-devel] KVM's signal masking

[Avi Kivity <avi@qumranet.com>]

Hollis Blanchard wrote:
> 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
>
>   

Yes.

> 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.

> 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.

-- 
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/