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

Kiryl Shutsemau <[email protected]>
Newsgroups org.kernel.vger.kvm,dev.linux.lists.linux-coco,org.kernel.vger.linux-kernel
Message-ID <aow2PIy1O1Z3iiej@thinkstation>
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/[email protected]/
> 
> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.