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
