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()?  Would having the caller acquire the lock solve the
problem?  Then it would be acquired from outside the IPI.


-- 
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.


-------------------------------------------------------------------------
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