Re: [PATCH v3 05/15] KVM: TDX: Move KVM_BUG_ON()s in __tdp_mmu_set_spte_atomic() to TDX code

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Returning a deterministic error (-EIO or -EBUSY) from mirror SPTE modification paths causes an unkillable in-kernel infinite loop in TDP MMU iterators, converting a VM-scoped bug into a host kernel hang.
--

commit e15424312043140d3e6eda83d94e044749575d32
Author: Rick Edgecombe <rick.p.edgecombe@intel.com>

KVM: TDX: Move KVM_BUG_ON()s in __tdp_mmu_set_spte_atomic() to TDX code

Drop some KVM_BUG_ON()s that are guarding against TDP MMU attempting to
propagate unsupported changes to the external page table through
__tdp_mmu_set_spte_atomic(). Have TDX code trigger them instead.

[ ... ]

> diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
> index 6a48bbab5f141..8e97af221b40e 100644
> --- a/arch/x86/kvm/vmx/tdx.c
> +++ b/arch/x86/kvm/vmx/tdx.c
> @@ -1717,6 +1717,9 @@ static int tdx_sept_set_private_spte(struct kvm *kvm, gfn_t gfn, u64 old_spte,
>  				     u64 new_spte, enum pg_level level)
>  {
> +	if (KVM_BUG_ON(is_shadow_present_pte(old_spte), kvm))
> +		return -EIO;
> +

[Severity: High]
This is a pre-existing issue, but does returning a deterministic error
(-EIO) here cause an unkillable in-kernel infinite loop in the TDP MMU
iterators?

Looking at the TDP MMU iterators, they evaluate the return value of
tdp_mmu_set_spte_atomic() and execute goto retry on any non-zero value,
assuming a transient cmpxchg race.

If tdx_sept_set_private_spte() returns -EIO, this propagates back to
__tdp_mmu_set_spte_atomic(), which restores the unmodified iter->old_spte
and returns the error:

arch/x86/kvm/mmu/tdp_mmu.c:__tdp_mmu_set_spte_atomic() {
    ...
		ret = kvm_x86_call(set_external_spte)(kvm, iter->gfn, iter->old_spte,
						      new_spte, iter->level);

		if (ret)
			__kvm_tdp_mmu_write_spte(iter->sptep, iter->old_spte);
    ...
		return ret;
}

Because the memory is restored and try_cmpxchg64() isn't used to update
iter->old_spte on this failure path, the local iterator state remains
unchanged. The loop retries, evaluates the exact same conditions, hits
the KVM_BUG_ON() again, and fails endlessly.

Since tdp_mmu_iter_cond_resched() refuses to yield without forward progress,
can this tight loop hold the RCU read lock and burn 100% CPU, leading to an
RCU stall or soft lockup?

Prior to this patch, the same livelock occurred when
__tdp_mmu_set_spte_atomic() returned -EBUSY directly, or when
set_external_spte() returned -EIO due to hardware rejection.

>  	if (KVM_BUG_ON(!is_shadow_present_pte(new_spte), kvm))
>  		return -EIO;
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260528080856.10141-1-yan.y.zhao@intel.com?part=5