Re: KVM: kvm_vcpu_block task state race

[Marcelo Tosatti <mtosatti@redhat.com>]

On Fri, May 09, 2008 at 06:09:41PM +0300, Avi Kivity wrote:
> Marcelo Tosatti wrote:
> >On Fri, May 09, 2008 at 10:40:47AM +0300, Avi Kivity wrote:
> >
> >  
> >>>Unfortunately it can't use wait_event_interruptible() due to
> >>>vcpu_put/vcpu_load.
> >>>
> >>> 
> >>>      
> >>schedule() will call vcpu_put()/vcpu_load() for us through preempt 
> >>notifiers.  I feel a little uneasy about it, but no concreate reason why 
> >>not to rely on it.
> >>    
> >
> >The preempt notifiers hook call kvm_arch_vcpu_load / kvm_arch_vcpu_put,
> >which won't unlock the vcpu mutex, right?
> >
> >  
> 
> Yes.
> 
> >I worry about a possible deadlock where some other operation that
> >requires the vcpu mutex happens but the vcpu thread itself is in hlt.
> >  
> 
> Suppose the guest executed a busy-spin waiting for an interrupt instead 
> of a hlt?  We need to be able to handle that too.

True.

> The best practice is to issue all vcpu ioctls from the thread that 
> created the vcpu; this becomes mandatory if we ever switch to a syscall 
> interface and remove the mutex.

For things like register dumps I don't believe its worthwhile. Much
simpler to stop the vcpu with SIG_IPI, retrieve registers, and run it
again (now that you mention the busy-spin, it is broken right now, if a
vcpu is spinning without exiting to userspace).

So do you want to give wait_event_interruptible() a try or wait for that
change until userspace never issues vcpu ioctl's to a possibly busy vcpu
(and go with the patch above)?


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone