This series is mostly about unlocking kvm->lock before synchronizing SRCU. Discussed at https://lore.kernel.org/kvm/Y7dN0Negds7XUbvI@xxxxxxxxxx/ . I'm mentioning the fact it's an optimization (not a bugfix; at least under the assumption that Xen does not break the lock order anymore) meant to reduce the time spent under the mutex. Sean, would that suffice? Along the way simplification and cleanups are smuggled. And, by the way, what about other sync-under-lock cases such as kvm_arch_vm_ioctl KVM_CREATE_PIT mutex_lock(&kvm->lock) kvm_create_pit() kvm_io_bus_register_dev() synchronize_srcu_expedited(&kvm->srcu) Does this qualify for some form of refactoring? Michal Luczaj (6): KVM: x86: Optimize kvm->lock and SRCU interaction (KVM_SET_PMU_EVENT_FILTER) KVM: x86: Optimize kvm->lock and SRCU interaction (KVM_X86_SET_MSR_FILTER) KVM: x86: Simplify msr_filter update KVM: x86: Explicitly state lockdep condition of msr_filter update KVM: x86: Remove unnecessary initialization in kvm_vm_ioctl_set_msr_filter() KVM: x86: Simplify msr_io() arch/x86/kvm/pmu.c | 3 +-- arch/x86/kvm/x86.c | 22 +++++++--------------- 2 files changed, 8 insertions(+), 17 deletions(-) -- 2.39.0
