Gregory Haskins wrote: > > >> We have a specialized signal mask for the kernel, and it is already in >> effect here. See KVM_SET_SIGNAL_MASK. >> >> > > KVM_SET_SIGNAL_MASK is precisely what I was trying to counteract ;). > Basically I was thinking that userspace could have set some arbitrary mask > that would be in effect at this time. My justification for unmasking > everything is two fold: > > 1) I think I really want *any* signal to kick the HLT, so I temporarily > unmask everything while halted. >
Signals are not yours, they're the user's. You can't return to the user with a signal if they're not prepared to handle it. > 2) Old userspace halting would not have the SET_SIGNAL_MASK set at the time > either, since we would have restored the original mask before returning to > userspace. > That's okay, old userspace won't have masked signals anyway. The purpose of having a different signal mask for the kernel and for userspace (which is what KVM_SET_SIGNAL_MASK does) is to be able to use signals without signal delivery (which is slow): - while in userspace, signals are blocked - enter kernel, unblock specified signals - signal happens, restore signal mask, return to userspace - userspace sees EINTR (bit signal is not delivered); can now use sigwait() to dequeue signal and process it. Without KVM_SET_SIGNAL_MASK, the signal handler is invoked for any unblocked signals. That's what current qemu wants; but we shall change it one day. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
