From mboxrd@z Thu Jan  1 00:00:00 1970
From: Avi Kivity <avi@qumranet.com>
Subject: Re: [kvm-ppc-devel] KVM's signal masking
Date: Fri, 15 Feb 2008 15:42:46 +0200
Message-ID: <47B596D6.4030500@qumranet.com>
References: <1203016758.24513.19.camel@basalt>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: kvm-devel <kvm-devel@lists.sourceforge.net>,
	kvm-ppc-devel <kvm-ppc-devel@lists.sourceforge.net>
To: Hollis Blanchard <hollisb@us.ibm.com>
Return-path: <kvm-devel-bounces@lists.sourceforge.net>
In-Reply-To: <1203016758.24513.19.camel@basalt>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/kvm-devel>,
	<mailto:kvm-devel-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=kvm-devel>
List-Post: <mailto:kvm-devel@lists.sourceforge.net>
List-Help: <mailto:kvm-devel-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/kvm-devel>,
	<mailto:kvm-devel-request@lists.sourceforge.net?subject=subscribe>
Sender: kvm-devel-bounces@lists.sourceforge.net
Errors-To: kvm-devel-bounces@lists.sourceforge.net
List-Id: kvm.vger.kernel.org

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/