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 _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
