From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
To: "linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"yilun.xu@linux.intel.com" <yilun.xu@linux.intel.com>,
"x86@kernel.org" <x86@kernel.org>
Cc: "Gao, Chao" <chao.gao@intel.com>,
"Xu, Yilun" <yilun.xu@intel.com>,
"Duan, Zhenzhong" <zhenzhong.duan@intel.com>,
"kas@kernel.org" <kas@kernel.org>,
"baolu.lu@linux.intel.com" <baolu.lu@linux.intel.com>,
"Li, Xiaoyao" <xiaoyao.li@intel.com>,
"Maloor, Kishen" <kishen.maloor@intel.com>,
"Hunter, Adrian" <adrian.hunter@intel.com>,
"tony.lindgren@linux.intel.com" <tony.lindgren@linux.intel.com>,
"Mehta, Sohil" <sohil.mehta@intel.com>,
"Fang, Peter" <peter.fang@intel.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"artem.bityutskiy@linux.intel.com"
<artem.bityutskiy@linux.intel.com>
Subject: Re: [PATCH 5/6] x86/virt/tdx: Make TDX module initialize the extensions
Date: Fri, 21 Aug 2026 23:55:21 +0000 [thread overview]
Message-ID: <f48b83feb2ee1d3c88b5a1627cf35b4b282d3f90.camel@intel.com> (raw)
In-Reply-To: <20260821032920.256225-6-yilun.xu@linux.intel.com>
On Fri, 2026-08-21 at 11:29 +0800, Xu Yilun wrote:
> TDX module extensions need memory for their own internal state and data
> to serve SEAMCALL leaves.
>
For "their own", I think "own" is superfluous.
> Several add-on features depend on the
> extensions to execute their SEAMCALL leaves.
>
> After providing all required memory to the TDX module, initialize TDX
> module extensions via TDH.EXT.INIT
>
What exactly does TDH.EXT.INIT actually do, and why can't whatever that is
happen during TDH.EXT.MEM.ADD? Not saying we need to jam anything in awkwardly.
Can we say this is analogous to TDH.SYS.CONFIG but for the extensions? It only
exists because SYS.CONFIG gives the features to enable before the memory is
there to actually do it. So it needs a second call?
> , then those add-on features can use
> their SEAMCALL leaves normally.
Out of curiosity, what happens if you don't complete these steps and call one of
the extension seamcalls?
>
> Signed-off-by: Xu Yilun <yilun.xu@linux.intel.com>
> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
> Reviewed-by: Tony Lindgren <tony.lindgren@linux.intel.com>
> Reviewed-by: Adrian Hunter <adrian.hunter@intel.com>
Code looks good. Except that it leaves me wondering if this could have all been
a while loop around tdh_sys_confg() that gives memory on a memory error code.
Actually it looks like we have a TDX_EXT_MEMORY_POOL_REQUIRED error code to use.
Consider something like this:
do {
ret = tdh_sys_init();
if (ret == TDX_EXT_MEMORY_POOL_REQUIRED)
tdh_ext_mem_add() //single page
while (ret == TDX_EXT_MEMORY_POOL_REQUIRED)
If that could technically work, I guess the benefit of the current approach is
that it allows to use contiguous physical allocations. Not sure if you think
that simpler snippet would actually be that simple in the real world. But if we
are basically building all this to help fragmentation, we should say it.
> ---
> v1:
> - Fix return value for SEAMCALL helpers (Chao)
> - Print SEAMCALL error code for SEAMCALL helpers (Xiaoyao)
> - Changelog & code comments
> ---
> arch/x86/virt/vmx/tdx/tdx.h | 1 +
> arch/x86/virt/vmx/tdx/tdx.c | 23 ++++++++++++++++++++++-
> 2 files changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/virt/vmx/tdx/tdx.h b/arch/x86/virt/vmx/tdx/tdx.h
> index 52888424fe7d..1f43d2eb2345 100644
> --- a/arch/x86/virt/vmx/tdx/tdx.h
> +++ b/arch/x86/virt/vmx/tdx/tdx.h
> @@ -48,6 +48,7 @@
> #define TDH_SYS_CONFIG 45
> #define TDH_SYS_SHUTDOWN 52
> #define TDH_SYS_UPDATE 53
> +#define TDH_EXT_INIT 60
> #define TDH_EXT_MEM_ADD 61
> #define TDH_SYS_DISABLE 69
>
> diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c
> index 8c2fdaf0b8c0..873b8393f32f 100644
> --- a/arch/x86/virt/vmx/tdx/tdx.c
> +++ b/arch/x86/virt/vmx/tdx/tdx.c
> @@ -1289,6 +1289,23 @@ static __init int tdx_ext_mem_setup(void)
> return ret;
> }
>
> +static __init int tdx_ext_init(void)
> +{
> + struct tdx_module_args args = {};
> + u64 ret;
> +
> + do {
> + ret = seamcall(TDH_EXT_INIT, &args);
What happens if no init is needed? Does it return success or error? I'm
wondering if we need to really check ext_required and can just call TDH_EXT_INIT
unconditionally. We need to check for TDX_FEATURES0_EXT in any case. But do we
need both checks?
> + } while (ret == TDX_INTERRUPTED_RESUMABLE);
> +
> + if (ret != TDX_SUCCESS) {
> + pr_err("TDH.EXT.INIT failed: 0x%016llx\n", ret);
> + return -EIO;
> + }
> +
> + return 0;
> +}
> +
> static __init int init_tdx_module_extensions(void)
> {
> int ret;
> @@ -1308,7 +1325,11 @@ static __init int init_tdx_module_extensions(void)
> if (!tdx_sysinfo.ext.ext_required)
> return 0;
>
> - return tdx_ext_mem_setup();
> + ret = tdx_ext_mem_setup();
> + if (ret)
> + return ret;
> +
> + return tdx_ext_init();
> }
>
> static __init int init_tdx_module(void)
next prev parent reply other threads:[~2026-08-21 23:55 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-21 3:29 [PATCH 0/6] Enable TDX module extensions Xu Yilun
2026-08-21 3:29 ` [PATCH 1/6] x86/virt/tdx: Wrap TDH.SYS.CONFIG/UPDATE operations in helpers Xu Yilun
2026-08-21 20:53 ` Edgecombe, Rick P
2026-08-21 3:29 ` [PATCH 2/6] x86/virt/tdx: Configure add-on features on TDX module init and update Xu Yilun
2026-08-21 14:38 ` Dave Hansen
2026-08-21 21:18 ` Edgecombe, Rick P
2026-08-21 22:01 ` Edgecombe, Rick P
2026-08-21 3:29 ` [PATCH 3/6] x86/virt/tdx: Detect if the extensions initialization is required Xu Yilun
2026-08-21 15:22 ` Kiryl Shutsemau
2026-08-21 22:22 ` Edgecombe, Rick P
2026-08-21 3:29 ` [PATCH 4/6] x86/virt/tdx: Add extra memory to TDX module for the extensions Xu Yilun
2026-08-21 15:44 ` Kiryl Shutsemau
2026-08-21 3:29 ` [PATCH 5/6] x86/virt/tdx: Make TDX module initialize " Xu Yilun
2026-08-21 23:55 ` Edgecombe, Rick P [this message]
2026-08-21 3:29 ` [PATCH 6/6] x86/virt/tdx: Re-initialize the extensions on runtime TDX module update Xu Yilun
2026-08-22 0:01 ` Edgecombe, Rick P
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=f48b83feb2ee1d3c88b5a1627cf35b4b282d3f90.camel@intel.com \
--to=rick.p.edgecombe@intel.com \
--cc=adrian.hunter@intel.com \
--cc=artem.bityutskiy@linux.intel.com \
--cc=baolu.lu@linux.intel.com \
--cc=chao.gao@intel.com \
--cc=kas@kernel.org \
--cc=kishen.maloor@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=peter.fang@intel.com \
--cc=sohil.mehta@intel.com \
--cc=tony.lindgren@linux.intel.com \
--cc=x86@kernel.org \
--cc=xiaoyao.li@intel.com \
--cc=yilun.xu@intel.com \
--cc=yilun.xu@linux.intel.com \
--cc=zhenzhong.duan@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.