Re: [PATCH 3/4] KVM: x86/mmu: Top-up memory caches when retrying "map private PFN"

On Fri, Aug 07, 2026, Rick P Edgecombe wrote:
> On Thu, 2026-08-06 at 14:40 -0700, Sean Christopherson wrote:
> > When mapping a private PFN in TDX's post-populate callback, top-up the
> > memory caches on every attempt to map the PFN to harden against bugs in the
> > map flow that could consume cache entries even if mapping ultimately fails.
> > E.g. as pointed out by Sashiko, the in-progress Dynamic PAMT support could
> > consume PAMT cache entries on TDX-Module lock contention.
> 
> I think it is the same for the other caches consumed by the fault. I guess
> "e.g." covers it. But it's not new after DPAMT.

I don't think so?  Especially since as you point out below, nothing else can
muck with the SPTEs.  The TDP MMU only consumes an cache entry if it successfully
creates a SPTE, and since nothing can muck with SPTEs, anything created on the
first attempt will still be there on subsequent attempts.  I.e. the TDP MMU might
create SPTEs that are ultimately unused, but I don't think it can exhaust a cache.

> > Harden KVM even though consuming an entry on failure is considered a KVM
> > bug, as retry is uncommon
> > 
> 
> The locks held by the sole call path will prevent retries from being needed due
> to TDX-specific details. So in the place where this code lives, it is a bug. But
> can't really be hit. To me "retry is uncommon" sounds like it's a rare case that
> is hittable. I guess you mean only in the uncommon case of bugs.

Ah, I was thinking a different task could pre-fault memory, but pre-fault isn't
allowed until the VM is TD_STATE_RUNNABLE, and KVM_TDX_INIT_MEM_REGION is only
usable if the VM is *not* TD_STATE_RUNNABLE.