Re: [PATCH v6 08/11] x86/tdx: Add APIs to support Dynamic PAMT ops from KVM's fault path

[Yan Zhao <yan.y.zhao@intel.com>]

On Fri, Jul 10, 2026 at 09:34:48AM +0800, Edgecombe, Rick P wrote:
> On Thu, 2026-07-09 at 15:17 +0800, Yan Zhao wrote:
> > On Mon, May 25, 2026 at 07:35:12PM -0700, Rick Edgecombe wrote:
> > > When handling an EPT violation, KVM holds a spinlock while manipulating
> > > the EPT. Before entering the spinlock it doesn't know how many EPT page
> > > tables will need to be installed or whether a huge page will be used. For
> > > this reason it allocates a worst case number of page tables that it might
> > > need as part of servicing the EPT violation.
> > > 
> > > Under Dynamic PAMT these pre-allocated pages will potentially need to have
> > > Dynamic PAMT backing pages installed for them. KVM already has helpers to
> > > manage topping up page caches before taking the MMU lock, but they cannot be
> > > passed from KVM to arch/x86 code.
> > > 
> > > The problem of how and when to install the DPAMT backing pages for the
> > > pages given to the TDX module during the fault path has had a lot of
> > > design attempts.
> > >  - Extracting KVM's MMU caches requires too much inlined code added to
> > >    headers.
> > >  - A few varieties of installing Dynamic PAMT backing when allocating the
> > >    S-EPT page tables. [0][1]
> > IIUC, [0][1] here refer to design attempts that had various problems, right?
> > However, [1] looks exactly like the one being adopted in v6?
> > 
> > Did you paste a wrong link? Should [1] instead be
> > https://lore.kernel.org/kvm/20260129011517.3545883-21-seanjc@google.com or
> > https://lore.kernel.org/kvm/aYYCOiMvWfSJR1AL@google.com ?
> 
> Oh yea... I think it should be:
> Kai's original idea: https://lore.kernel.org/kvm/aXENNKjAKTM9UJNH@google.com/
> Sean's fixup of it:
> https://lore.kernel.org/kvm/20260129011517.3545883-20-seanjc@google.com/
> The problem with Sean's:
> https://lore.kernel.org/kvm/aYW5CbUvZrLogsWF@yzhao56-desk.sh.intel.com/
> 
> TBH I'm a little on the fence about how useful the links will be in general. If
> someone tries to rip it out, it would be good breadcrumbs I guess
No problem. I am fine with either keeping or removing those links :)