Re: [PATCH 3/5] KVM: Adds ability to preepmt an executing VCPU

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

Gregory Haskins wrote:
>>>> On Sun, Apr 22, 2007 at  4:50 AM, in message <462B21C7.2060007-atKUWr5tajBWk0Htik3J/w@public.gmane.org>,
>>>>         
> Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote: 
>   
>> Gregory Haskins wrote:
>>     
>>>  	/*
>>> +	 * Signal that we have transitioned back to host mode 
>>> +	 */
>>> +	spin_lock_irqsave(&vcpu- >irq.lock, irq_flags);
>>> +	vcpu- >irq.guest_mode = 0;
>>> +	spin_unlock_irqrestore(&vcpu- >irq.lock, irq_flags);
>>> +
>>>   
>>>       
>> You need to check for an interrupt here. Otherwise you might go back to 
>> user mode and sleep there, no?
>>     
>
>
> It's subtle, but I'm not sure if you need to or not.  I'm glad you brought it up because its something I wanted to talk about.  The case where interrupts are raised outside the guest_mode brackets is obviously handled since we inject a signal, so the area in question is while guest_mode  = 1.
>
> In the simple case, an async-interrupt comes in and sends an IPI to cause a VMEXIT.  The guest exits with an EXTERNAL_INTERRUPT exception (IIUC), and the current handler causes the system to loop back into the VMENTER code (and thus injecting the interrupt).
>   

Okay.

> If the guest exits because of HLT, this is also handled since the current handle_halt() code checks if there are pending interrupts first before allowing the halt.   If there are interrupts, its loops back into VMENTER.
>   

Okay.

> For other cases, (e.g. the guest is VMEXITing for a reason other than the IPI)  the guest may need some userspace assistance:  e.g. MMIO servicing, exception handling, etc..  In this case, looping back to VMENTER would be incorrect.  The current code already handles this correctly too.  However, the potential problem (as you pointed out) is if the userspace wants to sleep after servicing those types of requests, but doesn't realize that it cannot due to a pending interrupt.  I currently am not sure if this is a problem or not since halt is handled.  
>   

I'm not sure either.  It seems natural to assume that qemu will re-enter
the guest without sleeping except for hlt.

> Are there any other userspace sleeps that we need to handle (e.g. maybe AIO)?  If so, one way to handle this is to mark the exportable state of the VCPU such that userspace can tell if interrupts are pending.  However, I'm not really sure if this is the best way to do it or if it can be easily done in a way that doesn't break ABI compatiblity.  Please advise. 
>   

The ABI can be extended by adding fields to struct kvm_vcpu_run and an
extension check to indicate their availability.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


-------------------------------------------------------------------------
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/