From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hollis Blanchard Subject: KVM's signal masking Date: Thu, 14 Feb 2008 13:19:18 -0600 Message-ID: <1203016758.24513.19.camel@basalt> Reply-To: Hollis Blanchard Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-ppc-devel To: kvm-devel Return-path: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces@lists.sourceforge.net Errors-To: kvm-devel-bounces@lists.sourceforge.net List-Id: kvm.vger.kernel.org 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/