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

[Chao Gao]

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]
> - Using mempool_t to transfer the pages between KVM and arch/x86 doesn't
>   work because it is the component is designed more around maintaining a
>   pool of pages, rather than topping up a continually drained cache.
>
>So don't do these as they all had various problems. Instead just create a
>small simple data structure to use for handing a pre-allocated list of
>pages between KVM and arch/x86 code. Model this on KVM's existing MMU
>memory caches.
>
>Add a tdx_pamt_cache arg to tdx_pamt_get() so it can draw pages from a
>cache when needed. Not all DPAMT page installations will happen under
>spinlock, for example control pages. So have tdx_pamt_get() maintain the
>existing behavior of allocating from the page allocator when NULL is
>passed for the struct tdx_pamt_cache arg. This prevents excess allocations
>for cases where it can be avoided.
>
>Export the new helpers for KVM.
>
>Assisted-by: GitHub Copilot:claude-opus-4-6 Claude:claude-opus-4-7
>Co-developed-by: Sean Christopherson <seanjc@xxxxxxxxxx>
>Signed-off-by: Sean Christopherson <seanjc@xxxxxxxxxx>
>Signed-off-by: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx>

Reviewed-by: Chao Gao <chao.gao@xxxxxxxxx>