Re: [PATCH v4 3/6] x86/virt/tdx: Add extra memory to TDX module for the extensions

[Edgecombe, Rick P]

On Tue, 2026-10-13 at 23:28 +0800, Xu Yilun wrote:
> TDX module extensions need memory for their execution environment to
> serve SEAMCALL leafs. The TDX architecture implements the extensions
> in such a way that they use the memory outside of SEAM range, so the
> kernel should add the memory upfront at initialization time.
> 
> Introduce a new memory adding process backed by a new SEAMCALL leaf
> TDH.EXT.MEM.ADD. The kernel queries TDX module how much memory needed,
> allocates it, adds it to the module, and never gets it back.
> 
> The TDX module accepts the memory in the form of an HPA array. This
> array is passed via a single 64-bit SEAMCALL leaf parameter, which
> encodes two values: the PFN of the container page holding the array, and
> the number of entries in the array. Create a helper to encode this
> format and name it after the TDX module term: HPA_LIST_INFO.
> 
> TDX module extensions consume tens of megabytes memory that will never
> be returned to the host. Use contiguous page allocation to isolate these
> large blocks entirely. This is a simple way to avoid permanent memory
> fragmentation: requiring the full size to be contiguous is more
> expensive than needed but should be good during the boot time. Print the
> allocation amount on TDX module extensions initialization for
> visibility.
> 
> The TDX module provides a metadata field "required_pages" to indicate
> the required memory size. This metadata is present only when the module
> supports the extensions and is meaningful only after the add-on feature
> configuration. Don't read and cache the metadata in tdx_sysinfo at the
> very beginning of TDX module initialization. Instead read it right
> before allocating memory for the extensions, when it is guaranteed to be
> valid.
> 
> AI was used under supervision to review code and workshop logs.
> 
> Signed-off-by: Xu Yilun <yilun.xu@xxxxxxxxxxxxxxx>
> Reviewed-by: Tony Lindgren <tony.lindgren@xxxxxxxxxxxxxxx>
> Reviewed-by: Kiryl Shutsemau (Meta) <kas@xxxxxxxxxx>

Reviewed-by: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx>