Re: [RFC PATCH v2 1/2] x86/virt/seamldr: Support large TDX module binaries

[Chao Gao <chao.gao@intel.com>]

On Tue, Nov 10, 2026 at 02:34:17PM +0800, Binbin Wu wrote:
>>> pages. The last entry of each page then points to the entry right after
>>> it, which starts the next page. These link entries do not hold module
>>> pages, so leave them out of the maximum module page count.
>>>
>>> The 16-page size is somewhat arbitrary. It fits modules of up to about
>>> 32MB, far above the roughly 2MB of current modules. It wastes 60KB for
>>> today's modules, which is fine because the memory is freed right after
>>> the update. Sizing module_pages_pa_list[] per module would mean either
>>> moving the allocation after the image header is validated, or allocating
>>> from an unvalidated page count. Either way it is more code churn.
>>>
>>> Do not query P-SEAMLDR for chaining support. Userspace selects the update
>>> image and is responsible for ensuring the module is compatible with
>>> P-SEAMLDR.
>
>Although the change log above has mentioned "For a module over 495 pages,
>...", a 496-page module was compatible with the P-SEAMLDR without chaining
>support, but now it requires P-SEAMLDR with chaining support.  Is it worth
>calling out this change to userspace?

Yes. I will call out this behavior change in the changelog and explain why
it does not break backward compatibility.

>>>  /*
>>>   * Serialize P-SEAMLDR calls since the hardware only allows a single CPU to
>>> @@ -129,17 +140,24 @@ struct tdx_image {
>>>  /*
>>>   * Given a vmalloc() allocation, write all of the backing physical
>>>   * addresses to pa_list[]. Caller guarantees that the array is big
>>> - * enough.
>>> + * enough. If pa_list[] spans multiple pages, point the last entry
>>> + * of each page to the next page.
>
>I was wondering why SEAMLDR_MAX_NR_MODULE_PAGES	is not
>(SEAMLDR_NR_MODULE_PA_ENTRIES - SEAMLDR_PARAMS_NR_PAGES + 1), since I thought
>the last page should all be the addresses for module pages.
>
>But I find the code below always treats the last entry of a page as the pointer
>to the next page, i.e. SEAMLDR_MAX_NR_MODULE_PAGES is indeed
>(SEAMLDR_NR_MODULE_PA_ENTRIES - SEAMLDR_PARAMS_NR_PAGES), but I am not sure the
>comment is clear enough.

Right. The last entry of a page never holds a module page, and the last page is
no exception. I will call out this in the comment below:

/*
 * module_pages_pa_list[] has 496 entries in the first page and 512 in
 * each following page. The last entry of each page is reserved to point
 * to the next page and cannot hold a module page. This applies to the
 * final page too.
 */
#define SEAMLDR_NR_MODULE_PA_ENTRIES    (496 + 512 * (SEAMLDR_PARAMS_NR_PAGES - 1))
#define SEAMLDR_MAX_NR_MODULE_PAGES     (SEAMLDR_NR_MODULE_PA_ENTRIES - SEAMLDR_PARAMS_NR_PAGES)