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

[Kiryl Shutsemau <kas@kernel.org>]

On Mon, Aug 24, 2026 at 05:18:25PM +0800, Xu Yilun wrote:
> > > +	hpa_list = kzalloc_obj(*hpa_list);
> > > +	if (!hpa_list)
> > > +		return -ENOMEM;
> > 
> > to_hpa_list_info() expects hpa_list to be page-aligned. It happens to
> > work with kmalloc for PAGE_SIZE allocation.
> 
> The struct tdx_hpa_list definition follows the TDX ABI and is guarenteed
> to be PAGE_SIZE by:
> 
> 	static_assert(sizeof(struct tdx_hpa_list) == PAGE_SIZE);
> 
> and kmalloc guarentees the page alignment.
> 
> 	59bb47985c1d ("mm, sl[aou]b: guarantee natural alignment for kmalloc(power-of-two)")
> 
> So I think it's OK, not "happen to work".
> 
> > 
> > Maybe it is better to allocate it with buddy allocator instead?
> 
> It can be, but then we need an extra variable to record the
> struct page *, which seems redundant?

__get_free_page() returns virtual address. No struct pages needed.

But, with explanation above, I am okay with kmalloc. Just add a comment.

> > > +
> > > +	page = alloc_contig_pages(required_pages, GFP_KERNEL, numa_mem_id(),
> > > +				  &node_online_map);
> > 
> > Why contiguous? TDH.EXT.MEM.ADD takes a list of page addresses and the loop
> > below writes every one of them out separately.
> > 
> > alloc_pages_bulk() fits the chunking that is already here, and a short
> > return can be handled per chunk. alloc_contig_pages() isolates and migrates
> > to get its range and fails TDX init outright when it cannot find one. PAMT
> 
> Yeah, this is not the ABI requirement, but the kernel's consideration. A
> brief reasoning in the commit log: avoiding permanent memory fragmentation
> and buddy allocator efficiency loss.
> 
> Also there is some discussion:
> 
> https://lore.kernel.org/all/167d9540-2d9a-4367-bc68-b96494bc4044@intel.com/
> 
> TL;DR
>   - The memory will never return to the kernel.
>   - There is chance that this tens of megabytes will fragment tens of
>     gigabytes of memory forever.
>   - The chance of fragmentation is actually low since at boot up, but
>     let the buddy allocator take care of these never-returned memory
>     is not necessary and lowers its efficiency.

I think it deserves a comment.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov