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

[Edgecombe, Rick P]

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.

> 
> 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?