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

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

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

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-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel

KVM's signal masking

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

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/

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

[Avi Kivity]

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/
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel

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

[Avi Kivity]

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/