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. - To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
