mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Chao Gao <chao.gao@intel.com>
To: Xu Yilun <yilun.xu@linux.intel.com>
Cc: <linux-kernel@vger.kernel.org>, <linux-coco@lists.linux.dev>,
	<kvm@vger.kernel.org>, <yilun.xu@intel.com>,
	<arjan.van.de.ven@intel.com>, Thomas Gleixner <tglx@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, "Borislav Petkov" <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>, <x86@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Kiryl Shutsemau <kas@kernel.org>,
	Rick Edgecombe <rick.p.edgecombe@intel.com>
Subject: Re: [RFC PATCH v2 1/2] x86/virt/seamldr: Support large TDX module binaries
Date: Thu, 12 Nov 2026 12:05:35 +0800	[thread overview]
Message-ID: <avU7Dz3IFylm7Tae@intel.com> (raw)
In-Reply-To: <avShYPmuMItx/tsJ@yilunxu-OptiPlex-7050>

On Thu, Nov 12, 2026 at 01:09:52AM +0800, Xu Yilun wrote:
>On Fri, Nov 06, 2026 at 05:21:55AM -0800, Chao Gao wrote:
>> The module binary is handed to P-SEAMLDR as a list of page physical
>> addresses in 'struct seamldr_params'. The list has 496 entries, which
>
>Is it better we specify why 496 entries?
>
>  The struct seamldr_params is contained in a 4KB page, the first 128
>  bytes of the page are the metadata, the rests are the list of page
>  phsical addresses for the module binary.

...

>
>
>> caps a module at 496 pages.
>> 
>> TDX modules are gaining features and are about to outgrow that limit.
>> 
>> The P-SEAMLDR ABI was extended to chain the list across 4KB pages. For
>
>With the knowledge of the first 4KB page, it is nature to say the ABI
>extends the list to more 4KB pages.
>
>> a module over 495 pages, the last of the 496 entries points to another
>> page of entries instead of to a module page. The last entry of that
>
>Maybe we don't have to emphasize the 495/496? The last entry of each
>page points to the next page.

I would rather drop 496 and 495 from these paragraphs. Readers do not
need the exact limit here, since the code has the numbers. How about:


The module binary is handed to P-SEAMLDR as a list of page physical
addresses in 'struct seamldr_params'. The list must fit in a single 4KB
page along with a few other fields, which caps a module at just under
2MB.

TDX modules are gaining features and are about to outgrow that limit.

The P-SEAMLDR ABI was extended to continue the list on more chained 4KB
pages. The last u64 of each page holds the physical address of the next
page in the chain.

>
>> page can point to yet another page, and so on, until every module page
>> is listed.
>> 
>
>[...]
>
>> -#define SEAMLDR_MAX_NR_MODULE_PAGES	496
>> +/*
>> + * module_pages_pa_list[] spans multiple pages. The last entry of each
>> + * page points to the next page and does not hold a module page, so the
>> + * maximum number of module pages is the array size minus one entry per
>> + * page.
>> + *
>> + * SEAMLDR_PARAMS_NR_PAGES is somewhat arbitrary. It allows modules of
>> + * up to about 32MB. Increase it if modules outgrow that.
>> + */
>> +#define SEAMLDR_PARAMS_NR_PAGES		16
>> +#define SEAMLDR_NR_MODULE_PA_ENTRIES	(496 + 512 * (SEAMLDR_PARAMS_NR_PAGES - 1))
>
>The number 496 is not meaningful when the seamldr_params is no longer
>one page size. We need comments to explain how it is derivee. But instead
>of text explanation, is it better:
>
>#define SEAMLDR_NR_MODULE_PA_ENTRIES	(SEAMLDR_PARAMS_NR_PAGES * 512 - 16)

The 16 here would still need explaining. It would also be confusing,
because the macro right below subtracts a different 16
(SEAMLDR_PARAMS_NR_PAGES) to get SEAMLDR_MAX_NR_MODULE_PAGES.

>
>Or:
>
>#define SEAMLDR_NR_MODULE_PA_ENTRIES	\
>	((SEAMLDR_PARAMS_NR_PAGES * PAGE_SIZE -	\
>	  offsetof(struct seamldr_params, module_pages_pa_list)) / \
>	 sizeof(u64))

offsetof() does not work here. The macro sizes module_pages_pa_list[]
inside 'struct seamldr_params', where the struct is still incomplete. The
compiler reports:

	error: invalid use of undefined type 'struct seamldr_params

How about:

/*
 * module_pages_pa_list[] fills the rest of 'struct seamldr_params' after
 * its first 128 bytes. The last entry of each page is reserved to point
 * to the next page and cannot hold a module address. The last entry of
 * the final page is never used.
 */
#define SEAMLDR_NR_MODULE_PA_ENTRIES	(((SEAMLDR_PARAMS_NR_PAGES * PAGE_SIZE - 128)) / sizeof(u64))
#define SEAMLDR_MAX_NR_MODULE_PAGES	(SEAMLDR_NR_MODULE_PA_ENTRIES - SEAMLDR_PARAMS_NR_PAGES)

>
>> +#define SEAMLDR_MAX_NR_MODULE_PAGES	(SEAMLDR_NR_MODULE_PA_ENTRIES - SEAMLDR_PARAMS_NR_PAGES)
>>  #define SEAMLDR_MAX_NR_SIG_PAGES	1
>>  
>>  /*
>> @@ -48,10 +59,10 @@ struct seamldr_params {
>>  	u64	sigstruct_pages_pa_list[SEAMLDR_MAX_NR_SIG_PAGES];
>>  	u8	reserved[104];
>>  	u64	module_nr_pages;
>> -	u64	module_pages_pa_list[SEAMLDR_MAX_NR_MODULE_PAGES];
>> +	u64	module_pages_pa_list[SEAMLDR_NR_MODULE_PA_ENTRIES];
>>  } __packed;
>>  
>> -static_assert(sizeof(struct seamldr_params) == 4096);
>> +static_assert(sizeof(struct seamldr_params) == SEAMLDR_PARAMS_NR_PAGES * PAGE_SIZE);

  reply	other threads:[~2026-11-12  4:05 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-06 13:21 [RFC PATCH v2 0/2] TDX: P-SEAMLDR: Support large TDX modules and sigstructs Chao Gao
2026-11-06 13:21 ` [RFC PATCH v2 1/2] x86/virt/seamldr: Support large TDX module binaries Chao Gao
2026-11-09 22:34   ` Edgecombe, Rick P
2026-11-10  6:34     ` Binbin Wu
2026-11-11  8:45       ` Chao Gao
2026-11-11  7:57     ` Chao Gao
2026-11-11 17:15       ` Xu Yilun
2026-11-11 17:09   ` Xu Yilun
2026-11-12  4:05     ` Chao Gao [this message]
2026-11-06 13:21 ` [RFC PATCH v2 2/2] x86/virt/seamldr: Support multiple sigstruct pages Chao Gao
2026-11-09 22:12   ` Edgecombe, Rick P
2026-11-09 22:19     ` Dave Hansen
2026-11-11  7:24     ` Chao Gao
2026-11-11 18:17   ` Xu Yilun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=avU7Dz3IFylm7Tae@intel.com \
    --to=chao.gao@intel.com \
    --cc=arjan.van.de.ven@intel.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=kas@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rick.p.edgecombe@intel.com \
    --cc=tglx@kernel.org \
    --cc=x86@kernel.org \
    --cc=yilun.xu@intel.com \
    --cc=yilun.xu@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®