[PATCH v4 26/28] KVM: TDX: Guard VM state transitions with "all" the locks

[Huang, Kai]

On Thu, 2025-10-30 at 13:09 -0700, Sean Christopherson wrote:
> Acquire kvm->lock, kvm->slots_lock, and all vcpu->mutex locks when
> servicing ioctls that (a) transition the TD to a new state, i.e. when
> doing INIT or FINALIZE or (b) are only valid if the TD is in a specific
> state, i.e. when initializing a vCPU or memory region.  Acquiring "all"
> the locks fixes several KVM_BUG_ON() situations where a SEAMCALL can fail
> due to racing actions, e.g. if tdh_vp_create() contends with either
> tdh_mr_extend() or tdh_mr_finalize().
> 
> For all intents and purposes, the paths in question are fully serialized,
> i.e. there's no reason to try and allow anything remotely interesting to
> happen.  Smack 'em with a big hammer instead of trying to be "nice".
> 
> Acquire kvm->lock to prevent VM-wide things from happening, slots_lock to
> prevent kvm_mmu_zap_all_fast(), and _all_ vCPU mutexes to prevent vCPUs
> from interefering.  Use the recently-renamed kvm_arch_vcpu_unlocked_ioctl()
       ^
       interfering

> to service the vCPU-scoped ioctls to avoid a lock inversion problem, e.g.
> due to taking vcpu->mutex outside kvm->lock.
> 
> See also commit ecf371f8b02d ("KVM: SVM: Reject SEV{-ES} intra host
> migration if vCPU creation is in-flight"), which fixed a similar bug with
> SEV intra-host migration where an in-flight vCPU creation could race with
> a VM-wide state transition.
> 
> Define a fancy new CLASS to handle the lock+check => unlock logic with
> guard()-like syntax:
> 
>         CLASS(tdx_vm_state_guard, guard)(kvm);
>         if (IS_ERR(guard))
>                 return PTR_ERR(guard);
> 
> to simplify juggling the many locks.
> 
> Note!  Take kvm->slots_lock *after* all vcpu->mutex locks, as per KVM's
> soon-to-be-documented lock ordering rules[1].
> 
> Link: https://lore.kernel.org/all/20251016235538.171962-1-seanjc@google.com [1]
> Reported-by: Yan Zhao <yan.y.zhao at intel.com>
> Closes: https://lore.kernel.org/all/aLFiPq1smdzN3Ary@yzhao56-desk.sh.intel.com
> Signed-off-by: Sean Christopherson <seanjc at google.com>

Reviewed-by: Kai Huang <kai.huang at intel.com>