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

[Vishal Annapurve]

On Fri, Aug 28, 2026 at 3:40 PM Edgecombe, Rick P
<rick.p.edgecombe@xxxxxxxxx> wrote:
>
> On Fri, 2026-08-28 at 15:18 -0700, Vishal Annapurve wrote:
> > > +
> > > +static int alloc_pamt_array(struct page **pamt_pages, struct tdx_pamt_cache
> > > *cache)
> > >   {
> > >          int i, j;
> > >
> > >          for (i = 0; i < TDX_DPAMT_ENTRY_PAGE_CNT; i++) {
> > > -               pamt_pages[i] = alloc_page(GFP_KERNEL_ACCOUNT);
> > > +               pamt_pages[i] = alloc_dpamt_page(cache);
> > >                  if (!pamt_pages[i])
> > >                          goto err;
> > >          }
> >
> > If the alloc_dpamt_page() was able to allocate a single page (not
> > two), should the partial allocation in the "err" handling return the
> > allocated page back to the cache?
>
> I think no? In the case of the cache not having sufficient pages, it is a bug.
> And if things go wrong, I don't see a risk of big security issue. So optimizing
> for more efficiently handling bug doesn't seem worth it.

Sounds good.

There is another allocation in tdx_pamt_get() that consumes the pages
from the dpamt page cache but returns memory back to the buddy
allocator. I think it's not particularly harmful, as the default
top-up should cover the maximum spt's in the fault path. But do you
have any additional thoughts on that?

>
> >
> > We observed similar failures internally with a slightly customized
> > setup which had retries for pamt cache allocations in the fault path
> > due to SEMCALL failures with older TDX module functionality.
>
> The best course of action is of course to fix the TDX module bug. I assume this
> already happened. This is the default upstream approach for that kind of thing
> across both subsystems. But it sounds like this case is even more special,
> because handling the specific bug would involve other code that is missing.
>
> That said, this code can definitely grow in the future if we seem some user
> value for something. But can we please just call this basic version good enough,
> and build on it later?

Sounds reasonable.