Re: [PATCH 10/10] KVM: Adds support for halting in the kernel

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

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/