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