[PATCH 0/5] KVM: Serialize vCPU creation and revert vcpu_ids tracking

[Sean Christopherson]

Serialize vCPU creation by holding kvm->lock for the entirety of
kvm_vm_ioctl_create_vcpu(), and then revert the now-redundant tracking adding
by commit 97d65b544f48 ("KVM: Check for duplicate vcpu_id as early as
possible").  I botched the math when justifying the vcpu_ids tracking; it's not
an extra 256 bytes, it's an extra 2048 bytes.  Roughly doubling the size of
"struct kvm" tripped x86's KVM_SANITY_CHECK_VM_STRUCT_SIZE, and obviously isn't
something we want to do in general.

The TL;DR of why it's a-ok to serialize vCPU creation is that no VMM actually
does parallel vCPU creation.  As with so many things, KVM's current behavior is
the result of decades-old cruft, not intentional, deliberate design.

Patch 1 is a tangentially related bug fix; I included it here because holding
kvm->lock for all of vCPU creation allows WARNing if KVM attempts to lock all
vCPUs if vCPU creation is in-progress (the caller is must hold kvm->lock).

Sean Christopherson (5):
  KVM: Reject attempts to lock all vCPUs if vCPU creation is in-progress
  KVM: Protect all of kvm_vm_ioctl_create_vcpu() with kvm->lock
  KVM: Move check for existing vCPU ID to the top of vCPU creation
  Revert "KVM: Check for duplicate vcpu_id as early as possible"
  KVM: WARN if vCPU creation is in-progress when locking all vCPUs

 arch/x86/kvm/svm/sev.c   | 10 ----------
 arch/x86/kvm/vmx/tdx.c   |  5 -----
 include/linux/kvm_host.h |  1 -
 virt/kvm/kvm_main.c      | 35 +++++++++++------------------------
 4 files changed, 11 insertions(+), 40 deletions(-)


base-commit: d599822bdb66aeec5ec76297b0fc6efaaeefe07c
-- 
2.55.0.1032.g73a4cd73de-goog