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.

Patches 1-3 are a tangentially related cleanups and bug fixes; I included them
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 must
hold kvm->lock).

v2:
 - Tweak patch 1's changelog to clarify that that only x86's manual checks are
   dropped. [Sashiko]
 - Add patches to convert additional arm64 and RISC-V usage to 
   kvm_is_vcpu_creation_in_progress(). [Sashiko]
 - Remove acquisition of kvm->lock from s390 and PPC vCPU creation flows.
   [Christian, Sashiko]
 - Add Jean-Christophe's Tested-by to the revert.

v1: https://lore.kernel.org/all/20260914181223.289061-1-seanjc@google.com

Sean Christopherson (7):
  KVM: Reject attempts to lock all vCPUs if vCPU creation is in-progress
  KVM: arm64: vgic: Rely on vCPU creation check in "trylock all vCPUs"
  KVM: RISC-V: Use kvm_is_vcpu_creation_in_progress() instead of
    open-coded equivalent
  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/arm64/kvm/vgic/vgic-init.c | 12 ++++-------
 arch/powerpc/kvm/book3s_hv.c    |  2 --
 arch/riscv/kvm/aia_device.c     |  2 +-
 arch/s390/kvm/s390/s390.c       |  5 +----
 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 +++++++++++----------------------
 8 files changed, 17 insertions(+), 55 deletions(-)


base-commit: d599822bdb66aeec5ec76297b0fc6efaaeefe07c
-- 
2.55.0.1082.g2b9226bbc0-goog

On Mon, Sep 21, 2026 at 10:44:38AM -0700, Sean Christopherson wrote:
> 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.
> 
> Patches 1-3 are a tangentially related cleanups and bug fixes; I included them
> 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 must
> hold kvm->lock).
> 
> v2:
>  - Tweak patch 1's changelog to clarify that that only x86's manual checks are
>    dropped. [Sashiko]
>  - Add patches to convert additional arm64 and RISC-V usage to 
>    kvm_is_vcpu_creation_in_progress(). [Sashiko]
>  - Remove acquisition of kvm->lock from s390 and PPC vCPU creation flows.
>    [Christian, Sashiko]
>  - Add Jean-Christophe's Tested-by to the revert.
> 
> v1: https://lore.kernel.org/all/20260914181223.289061-1-seanjc@google.com
> 
> Sean Christopherson (7):
>   KVM: Reject attempts to lock all vCPUs if vCPU creation is in-progress
>   KVM: arm64: vgic: Rely on vCPU creation check in "trylock all vCPUs"
>   KVM: RISC-V: Use kvm_is_vcpu_creation_in_progress() instead of
>     open-coded equivalent
>   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

This addresses the Secure TSC splat I reported previously:
https://lore.kernel.org/all/apgj5l7DZGsScsNc@blrnaveerao1/

I booted a SNP guest with Secure TSC enabled and didn't see any lockdep 
reports. For what that's worth:
Tested-by: Naveen N Rao (AMD) <naveen@kernel.org>


- Naveen

Hi Sean,

Just like for the first version, I tested the full V2 series with the
configuration that originally triggered the build failure
(CONFIG_DEBUG_KERNEL=n, CONFIG_KASAN=n).

The kernel builds successfully on adm64, and I booted the resulting
kernel and started two QEMU/KVM VMs without any issues.

Tested-by: Jean-Christophe Guillain <jean-christophe@guillain.net>

Thanks again !

Cheers,
Jean-Christophe Guillain