| Message ID | 20221102231911.3107438-5-seanjc@google.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | KVM: Rework kvm_init() and hardware enabling | expand |
On Wed, Nov 02 2022, Sean Christopherson <seanjc@google.com> wrote: > Move the call to kvm_vfio_ops_exit() further up kvm_exit() to try and > bring some amount of symmetry to the setup order in kvm_init(), and more > importantly so that the arch hooks are invoked dead last by kvm_exit(). > This will allow arch code to move away from the arch hooks without any > change in ordering between arch code and common code in kvm_exit(). > > That kvm_vfio_ops_exit() is called last appears to be 100% arbitrary. It > was bolted on after the fact by commit 571ee1b68598 ("kvm: vfio: fix > unregister kvm_device_ops of vfio"). The nullified kvm_device_ops_table > is also local to kvm_main.c and is used only when there are active VMs, > so unless arch code is doing something truly bizarre, nullifying the > table earlier in kvm_exit() is little more than a nop. > > Signed-off-by: Sean Christopherson <seanjc@google.com> > --- > virt/kvm/kvm_main.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Looks safe to me. Reviewed-by: Cornelia Huck <cohuck@redhat.com>
On Wed, 2022-11-02 at 23:18 +0000, Sean Christopherson wrote: > Move the call to kvm_vfio_ops_exit() further up kvm_exit() to try and > bring some amount of symmetry to the setup order in kvm_init(), and > more > importantly so that the arch hooks are invoked dead last by > kvm_exit(). > This will allow arch code to move away from the arch hooks without > any > change in ordering between arch code and common code in kvm_exit(). > > That kvm_vfio_ops_exit() is called last appears to be 100% > arbitrary. It > was bolted on after the fact by commit 571ee1b68598 ("kvm: vfio: fix > unregister kvm_device_ops of vfio"). The nullified > kvm_device_ops_table > is also local to kvm_main.c and is used only when there are active > VMs, > so unless arch code is doing something truly bizarre, nullifying the > table earlier in kvm_exit() is little more than a nop. > > Signed-off-by: Sean Christopherson <seanjc@google.com> > --- > virt/kvm/kvm_main.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Eric Farman <farman@linux.ibm.com>
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 8b7534cc953b..f592dd4ce8f2 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -5961,6 +5961,7 @@ void kvm_exit(void) for_each_possible_cpu(cpu) free_cpumask_var(per_cpu(cpu_kick_mask, cpu)); kmem_cache_destroy(kvm_vcpu_cache); + kvm_vfio_ops_exit(); kvm_async_pf_deinit(); unregister_syscore_ops(&kvm_syscore_ops); unregister_reboot_notifier(&kvm_reboot_notifier); @@ -5970,7 +5971,6 @@ void kvm_exit(void) free_cpumask_var(cpus_hardware_enabled); kvm_arch_hardware_unsetup(); kvm_arch_exit(); - kvm_vfio_ops_exit(); } EXPORT_SYMBOL_GPL(kvm_exit);
Move the call to kvm_vfio_ops_exit() further up kvm_exit() to try and bring some amount of symmetry to the setup order in kvm_init(), and more importantly so that the arch hooks are invoked dead last by kvm_exit(). This will allow arch code to move away from the arch hooks without any change in ordering between arch code and common code in kvm_exit(). That kvm_vfio_ops_exit() is called last appears to be 100% arbitrary. It was bolted on after the fact by commit 571ee1b68598 ("kvm: vfio: fix unregister kvm_device_ops of vfio"). The nullified kvm_device_ops_table is also local to kvm_main.c and is used only when there are active VMs, so unless arch code is doing something truly bizarre, nullifying the table earlier in kvm_exit() is little more than a nop. Signed-off-by: Sean Christopherson <seanjc@google.com> --- virt/kvm/kvm_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)