Re: [PATCH v3 6/6] x86/virt/tdx: Support DPAMT when adding memory for the extensions

[Kiryl Shutsemau <kas@kernel.org>]

On Sat, Oct 10, 2026 at 11:38:02AM +0800, Xu Yilun wrote:
> On Fri, Oct 09, 2026 at 02:28:34PM +0100, Kiryl Shutsemau wrote:
> > On Thu, Oct 08, 2026 at 12:39:20PM +0800, Xu Yilun wrote:
> > > On Tue, Oct 06, 2026 at 07:36:50AM +0300, Tony Lindgren wrote:
> > > > On Tue, Oct 06, 2026 at 01:41:50AM +0800, Xu Yilun wrote:
> > > > > The TDX module uses Physical Address Metadata Table (PAMT) to track some
> > > > > state for each page of physical memory that it might use. 3 levels of
> > > > > PAMTs are used to track pages of different sizes - 1GB, 2MB and 4KB.
> > > > > Dynamic PAMT (DPAMT) allows saving memory by allocating 4KB PAMT
> > > > > dynamically, while the 1GB and 2MB levels remain allocated on TDX module
> > > > > initialization. The kernel has helpers to install 4K DPAMT.
> > > > > 
> > > > > Although the memory for the extensions is tens of megabytes and the host
> > > > > allocates it in a large chunk, the TDX module accepts it at 4K
> > > > > granularity. Thus the host has to install 4K DPAMT for each page of it.
> > > > > 
> > > > > Call tdx_pamt_get() for each page before adding it to TDX module.
> > > > > Normally, these operations should not fail, and if they do,
> > > > > intentionally keep the error handling as simple as before - leak all
> > > > > pages, including the installed 4K DPAMT metadata.
> > > > > 
> > > > > Signed-off-by: Xu Yilun <yilun.xu@linux.intel.com>
> > > > > ---
> > > > > v3:
> > > > >  - New patch
> > > > > ---
> > > > >  arch/x86/virt/vmx/tdx/tdx.c | 9 ++++++++-
> > > > >  1 file changed, 8 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c
> > > > > index 5d5f9da1ab02..27a7039ee443 100644
> > > > > --- a/arch/x86/virt/vmx/tdx/tdx.c
> > > > > +++ b/arch/x86/virt/vmx/tdx/tdx.c
> > > > > @@ -1330,8 +1330,15 @@ static __init int tdx_ext_mem_setup(void)
> > > > >  		struct page *chunk = page + added_pages;
> > > > >  		unsigned int i;
> > > > >  
> > > > > -		for (i = 0; i < chunk_pages; i++)
> > > > > +		for (i = 0; i < chunk_pages; i++) {
> > > > > +			ret = tdx_pamt_get(page_to_pfn(chunk + i), NULL);
> > > > > +			if (ret) {
> > > > > +				WARN(1, "DPAMT setup error for extensions, stranded all pages\n");
> > > > > +				goto out_free_hpa_list;
> > > > > +			}
> > > > > +
> > > > >  			hpa_list->phys[i] = page_to_phys(chunk + i);
> > > > > +		}
> > > > >  
> > > > >  		ret = tdx_ext_mem_add(hpa_list, chunk_pages);
> > > > >  		if (ret) {
> > > > > 
> > > > 
> > > > How about just fold this change in into patch 3/6?
> > > 
> > > I think patch 3/6 is already quite heavy. Is it good that I put this
> > > patch right after patch 3/6?
> > 
> > But that breaks bisectability, no? Even placed right after 3/6, that
> > commit fails TDX module init on a machine with DPAMT and extensions
> > whenever the module asks for a non-zero pool.
> 
> It will not. Any patch for extension-backed features should be applied
> after this series. So the pool will always be zero until something like:
> 
>  /* List all kernel-supported add-on features0 bits here */
> -#define TDX_KERNEL_SUPPORTED_ADDON_FEATURES0   (0)
> +#define TDX_KERNEL_SUPPORTED_ADDON_FEATURES0   (TDX_FEATURES0_QUOTE)

Okay, fair enough. Feel free to use my

Reviewed-by: Kiryl Shutsemau (Meta) <kas@kernel.org>

on 3/6 and 6/6.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov