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