On Thu, 2025-10-30 at 13:09 -0700, Sean Christopherson wrote: > From: Yan Zhao <[email protected]> > > During vCPU creation, a vCPU may be destroyed immediately after > kvm_arch_vcpu_create() (e.g., due to vCPU id confiliction). However, the > vcpu_load() inside kvm_arch_vcpu_create() may have associate the vCPU to > pCPU via "list_add(&tdx->cpu_list, &per_cpu(associated_tdvcpus, cpu))" > before invoking tdx_vcpu_free(). > > Though there's no need to invoke tdh_vp_flush() on the vCPU, failing to > dissociate the vCPU from pCPU (i.e., "list_del(&to_tdx(vcpu)->cpu_list)") > will cause list corruption of the per-pCPU list associated_tdvcpus. > > Then, a later list_add() during vcpu_load() would detect list corruption > and print calltrace as shown below. > > Dissociate a vCPU from its associated pCPU in tdx_vcpu_free() for the vCPUs > destroyed immediately after creation which must be in > VCPU_TD_STATE_UNINITIALIZED state. > > kernel BUG at lib/list_debug.c:29! > Oops: invalid opcode: 0000 [#2] SMP NOPTI > RIP: 0010:__list_add_valid_or_report+0x82/0xd0 > > Call Trace: > <TASK> > tdx_vcpu_load+0xa8/0x120 > vt_vcpu_load+0x25/0x30 > kvm_arch_vcpu_load+0x81/0x300 > vcpu_load+0x55/0x90 > kvm_arch_vcpu_create+0x24f/0x330 > kvm_vm_ioctl_create_vcpu+0x1b1/0x53 > kvm_vm_ioctl+0xc2/0xa60 > __x64_sys_ioctl+0x9a/0xf0 > x64_sys_call+0x10ee/0x20d0 > do_syscall_64+0xc3/0x470 > entry_SYSCALL_64_after_hwframe+0x77/0x7f > > Fixes: d789fa6efac9 ("KVM: TDX: Handle vCPU dissociation") > Signed-off-by: Yan Zhao <[email protected]> > Signed-off-by: Sean Christopherson <[email protected]>
Reviewed-by: Kai Huang <[email protected]>
