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
