On Mon, May 13, 2024, Kai Huang wrote: > On Fri, 2024-04-26 at 10:08 -0700, Sean Christopherson wrote: > > On Fri, Apr 26, 2024, Chao Gao wrote: > > > > diff --git a/arch/x86/kvm/vmx/x86_ops.h b/arch/x86/kvm/vmx/x86_ops.h > > > > index 502704596c83..afddfe3747dd 100644 > > > > --- a/arch/x86/kvm/vmx/x86_ops.h > > > > +++ b/arch/x86/kvm/vmx/x86_ops.h > > > > @@ -15,6 +15,7 @@ void vmx_hardware_unsetup(void); > > > > int vmx_check_processor_compat(void); > > > > int vmx_hardware_enable(void); > > > > void vmx_hardware_disable(void); > > > > +void vmx_emergency_disable(void); > > > > int vmx_vm_init(struct kvm *kvm); > > > > void vmx_vm_destroy(struct kvm *kvm); > > > > int vmx_vcpu_precreate(struct kvm *kvm); > > > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > > > > index e9ef1fa4b90b..12e88aa2cca2 100644 > > > > --- a/arch/x86/kvm/x86.c > > > > +++ b/arch/x86/kvm/x86.c > > > > @@ -9797,6 +9797,8 @@ int kvm_x86_vendor_init(struct kvm_x86_init_ops *ops) > > > > > > > > kvm_ops_update(ops); > > > > > > > > + cpu_emergency_register_virt_callback(kvm_x86_ops.emergency_disable); > > > > + > > > > > > vmx_emergency_disable() accesses loaded_vmcss_on_cpu but now it may be called > > > before loaded_vmcss_on_cpu is initialized. This may be not a problem for now > > > given the check for X86_CR4_VMXE in vmx_emergency_disable(). But relying on > > > that check is fragile. I think it is better to apply the patch below from Isaku > > > before this patch. > > > > > > https://lore.kernel.org/kvm/c1b7f0e5c2476f9f565acda5c1e746b8d181499b.1708933498.git.isaku.yamahata@xxxxxxxxx/ > > > > Agreed, good eyeballs, and thanks for the reviews! > > > > I think we can even move registering this emergency disable to > hardware_enable_all()? It seems there's no reason to register the > callback if hardware_enable_all() hasn't been attempted. Hmm, we could. I don't know that it'd be worth doing though. I suppose one could argue that it would allow out-of-tree hypervisors to more easily co-exist with KVM, but I haven't heard/seen anyone crying for that. And it would be nice to have all of this code in one location. I think we'd need more explicit synchronization if the callback is registered on-demand, but that should be a relatively minor, if it's even needed. So yeah, I'll give this a shot and go this route for v2 if it works out.
