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