Re: BUILD_BUG_ON failed for kvm_vmx struct size sanity check in vmx.c

[Sean Christopherson <seanjc@google.com>]

On Wed, Sep 02, 2026, Naveen N Rao wrote:
> On Mon, Aug 31, 2026 at 05:52:48PM -0700, Sean Christopherson wrote:
> > On Fri, Aug 28, 2026, Sean Christopherson wrote:
> > > On Thu, Aug 27, 2026, Jean-Christophe Guillain wrote:
> > 
> > So, rather than trying to come up with a scheme that is performant without being
> > too complex, I'm planning on fixing this by simply holding kvm->lock for the entire
> > duration of vCPU creation, so that KVM doesn't need to do extra tracking and can
> > instead rely purely on the array of online vCPUs.  Then we can revert 97d65b544f48
> > and do more cleanups on top.
> 
> I was going to report the below lockdep splat I am seeing when trying to 
> enable Secure TSC due to commit ba903f738249 ("KVM: SEV: Assert that 
> kvm->lock is held when querying SEV+ support"). I believe this will also 
> be addressed if we continue to hold kvm->lock during vCPU creation:
> 
>   WARNING: arch/x86/kvm/svm/sev.c:136 at sev_snp_guest+0xb2/0xc0 [kvm_amd], CPU#170: CPU 0/KVM/5532
>   ...
>   Call Trace:
>    <TASK>
>    snp_is_secure_tsc_enabled+0x1a/0x40 [kvm_amd]
>    sev_vcpu_create+0x77/0xc0 [kvm_amd]
>    svm_vcpu_create+0x5f/0x160 [kvm_amd]
>    kvm_arch_vcpu_create+0x234/0x2f0 [kvm]
>    kvm_vm_ioctl+0x232/0x1c10 [kvm]
>    ? __lock_acquire+0x465/0x1b10
>    ? lock_acquire+0xbf/0x2f0
>    ? __fget_files+0x2b/0x190
>    ? find_held_lock+0x2b/0x80
>    __x64_sys_ioctl+0x97/0xe0
>    do_syscall_64+0xf3/0x880
>    ? exc_page_fault+0x128/0x270
>    entry_SYSCALL_64_after_hwframe+0x77/0x7f

Oh, right!  I forget about the wrinkles with kvm->lock not being held during
vCPU creation.  This is largely fudged around by the kvm_get_running_vcpu() check
since VMCB initialization is done with the vCPU loaded (i.e. "running").