>>> On Thu, May 24, 2007 at 4:29 AM, in message <[EMAIL PROTECTED]>,
Avi Kivity <[EMAIL PROTECTED]> wrote:
> Gregory Haskins wrote:
>> Halting in userspace requires a relatively cumbersome mechanism to signal
> the
>> halted VCPU. Implementing halt in kernel should be relatively straight
>> forward and it eliminates the need for the signaling
>>
>> /*
>> + * The vCPU has executed a HLT instruction with in- kernel mode enabled.
>> + */
>> +static int kvm_vcpu_kern_halt(struct kvm_vcpu *vcpu, struct kvm_run
> *kvm_run)
>> +{
>> + DECLARE_WAITQUEUE(wait, current);
>> + sigset_t sigblocked, sigsaved;
>> + int r = 1;
>> +
>> + /*
>> + * Unmask all signals while we wait
>> + */
>> + memset(&sigblocked, 0, sizeof(sigblocked));
>> + sigprocmask(SIG_SETMASK, &sigblocked, &sigsved);
>>
>
> 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.
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 being said, I am not an expert here so I may have got it wrong. Please
advise.
-Greg
-------------------------------------------------------------------------
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
