From: Xu Yilun <yilun.xu@linux.intel.com>
To: Chao Gao <chao.gao@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 01:09:52 +0800 [thread overview]
Message-ID: <avShYPmuMItx/tsJ@yilunxu-OptiPlex-7050> (raw)
In-Reply-To: <20261106132159.1551365-2-chao.gao@intel.com>
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.
> 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)
Or:
#define SEAMLDR_NR_MODULE_PA_ENTRIES \
((SEAMLDR_PARAMS_NR_PAGES * PAGE_SIZE - \
offsetof(struct seamldr_params, module_pages_pa_list)) / \
sizeof(u64))
> +#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);
next prev parent reply other threads:[~2026-11-11 17:17 UTC|newest]
Thread overview: 15+ 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 [this message]
2026-11-12 4:05 ` Chao Gao
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
2026-11-12 4:37 ` Chao Gao
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=avShYPmuMItx/tsJ@yilunxu-OptiPlex-7050 \
--to=yilun.xu@linux.intel.com \
--cc=arjan.van.de.ven@intel.com \
--cc=bp@alien8.de \
--cc=chao.gao@intel.com \
--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 \
/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®