On Fri, 2007-07-27 at 07:56 +0300, Avi Kivity wrote:
> Gregory Haskins wrote:
> > Hi guys,
> >   While working with the -rt kernel, I have noticed a problem in KVM.
> > Specifically, when you stop a VM you sometimes get a "sleep while
> > atomic" oopses.  It turns out that the issue is related to an
> > smp_function_call IPI that KVM does to remotely flush the VMX hardware
> > on shutdown.  The code tries to acquire the global kvm_lock (which is a
> > normal spinlock_t, of course converted to rt_mutex on -rt) from the
> > interrupt context of the IPI handler.  You know the rest of the
> > story....
> >
> > The obvious solution is to convert the kvm_lock to a raw_spinlock_t.
> > However, I really don't want to do this unless we absolutely have to
> > since it will just increase latencies for a good portion of the rest of
> > KVM.
> >   
> 
> Are you talking about decache_vcpus_from_cpu() that is called from
> hardware_disable()?  

Yeah, exactly.


> Would having the caller acquire the lock solve the
> problem?  

Possibly, though I would have to look at how/where the caller executes.
If its in_atomic, it will hit the same problem that the callee does.

That being said, I have no doubts that we can solve this particular KVM
issue much more simply then with what I am proposing.  What I am
wondering, however, is if this is an opportunity to further increase the
preemptibility of the RT kernel.  I figure, most drivers that use
hardirqs and spinlock_t continue to work transparently on PREEMPT_RT
because threaded IRQs can sleep (and be preempted)....why not FC-IPIs
too?

I'm partway done with a proof-of-concept patch.  Ill send it out later.



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Reply via email to