Thread (107 messages) 107 messages, 10 authors, 13d ago

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

From: Yan Zhao <hidden>
Date: 2026-07-10 02:47:49
Also in: kvm, linux-doc, lkml

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:
quoted
On Mon, May 25, 2026 at 07:35:12PM -0700, Rick Edgecombe wrote:
quoted
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 (local) or
https://lore.kernel.org/kvm/aYYCOiMvWfSJR1AL@google.com (local) ?
Oh yea... I think it should be:
Kai's original idea: https://lore.kernel.org/kvm/aXENNKjAKTM9UJNH@google.com/ (local)
Sean's fixup of it:
https://lore.kernel.org/kvm/20260129011517.3545883-20-seanjc@google.com/ (local)
The problem with Sean's:
https://lore.kernel.org/kvm/aYW5CbUvZrLogsWF@yzhao56-desk.sh.intel.com/ (local)

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 :)
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help