The way that KVM handles debugfs init/destroy is somewhat sloppy. Even
though debugfs is stood up after kvm_create_vm(), it is torn down from
kvm_destroy_vm(). There exists a window where we need to tear down a VM
before debugfs is created, requiring delicate handling.
This series cleans up the debugfs lifecycle by fully tying it to the
VM's init/destroy pattern.
First two patches hoist some unrelated stats initialization to a more
appropriate place for kvm and kvm_vcpu.
Second two patches are the meat of the series, changing around the
initialization order to get an FD early and wiring in debugfs
initialization to kvm_create_vm().
Lastly, patch 5 is essentially a revert of Sean's fix [1] for a NULL deref
in debugfs, though I stopped short of an outright revert since that one
went to stable and is still entirely correct.
Applies cleanly to v5.18-rc5, since [1] is currently missing from
kvm/queue or kvm/next. Tested with KVM selftests and the reproducer
mentioned in [1] on an Intel Skylake machine.
[1] 5c697c367a66 ("KVM: Initialize debugfs_dentry when a VM is created to avoid NULL deref")
v1: http://lore.kernel.org/r/20220415201542.1496582-1-oupton@xxxxxxxxxx
v1 -> v2:
- Don't conflate debugfs+stats. Initialize stats_id outside of the
context of debugfs (Sean)
- Pass around the FD as a string to avoid subsequent KVM changes
inappropriately using the FD (Sean)
Oliver Upton (5):
KVM: Shove vm stats_id init into kvm_create_vm()
KVM: Shove vcpu stats_id init into kvm_vcpu_init()
KVM: Get an fd before creating the VM
KVM: Actually create debugfs in kvm_create_vm()
KVM: Hoist debugfs_dentry init to kvm_create_vm_debugfs() (again)
virt/kvm/kvm_main.c | 96 +++++++++++++++++++++++----------------------
1 file changed, 49 insertions(+), 47 deletions(-)
--
2.36.1.124.g0e6072fb45-goog
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
