From: Nikolay Borisov <nik.borisov@suse.com>
To: Xu Yilun <yilun.xu@linux.intel.com>,
x86@kernel.org, linux-coco@lists.linux.dev,
linux-kernel@vger.kernel.org
Cc: kas@kernel.org, rick.p.edgecombe@intel.com, yilun.xu@intel.com,
xiaoyao.li@intel.com, sohil.mehta@intel.com,
adrian.hunter@intel.com, kishen.maloor@intel.com,
tony.lindgren@linux.intel.com, peter.fang@intel.com,
baolu.lu@linux.intel.com, zhenzhong.duan@intel.com,
chao.gao@intel.com, artem.bityutskiy@linux.intel.com,
kvm@vger.kernel.org
Subject: Re: [PATCH v2 3/5] x86/virt/tdx: Detect if the extensions initialization is required
Date: Tue, 29 Sep 2026 20:26:43 +0300 [thread overview]
Message-ID: <b88401eb-ebd8-41dd-8260-af3890886ca3@suse.com> (raw)
In-Reply-To: <20260915102658.713079-4-yilun.xu@linux.intel.com>
On 15.09.26 г. 13:26 ч., Xu Yilun wrote:
> Some add-on features require TDX module extensions. The TDX module
> provides a metadata field "ext_required" to indicate this requirement.
>
> Add the first step of TDX module extensions initialization by detecting
> if the extensions are required:
>
> 1. Check if the extensions are supported via TDX_FEATURES0_EXT. If
> not, ext_required is not readable.
> 2. Check if any TDX feature needs the extensions via ext_required.
>
> Skip the extensions initialization when it is not required.
>
> Currently all metadata fields are read at the very beginning of TDX
> module initialization. However, ext_required is only valid after the
> add-on feature configuration, so it cannot use the existing metadata
> reading method.
>
> Add a dedicated metadata reading interface for the extensions, call it
> after add-on feature configuration.
>
> Signed-off-by: Xu Yilun <yilun.xu@linux.intel.com>
> Reviewed-by: Tony Lindgren <tony.lindgren@linux.intel.com>
> ---
> v1:
> - Include struct tdx_sys_info_ext in struct tdx_sys_info.
> ---
> arch/x86/include/asm/tdx.h | 1 +
> arch/x86/include/asm/tdx_global_metadata.h | 5 ++++
> arch/x86/virt/vmx/tdx/tdx.c | 28 +++++++++++++++++++++
> arch/x86/virt/vmx/tdx/tdx_global_metadata.c | 14 +++++++++++
> 4 files changed, 48 insertions(+)
>
> diff --git a/arch/x86/include/asm/tdx.h b/arch/x86/include/asm/tdx.h
> index 89e97d5761d8..6657f2db0330 100644
> --- a/arch/x86/include/asm/tdx.h
> +++ b/arch/x86/include/asm/tdx.h
> @@ -36,6 +36,7 @@
> /* Bit definitions of TDX_FEATURES0 metadata field */
> #define TDX_FEATURES0_TD_PRESERVING BIT_ULL(1)
> #define TDX_FEATURES0_NO_RBP_MOD BIT_ULL(18)
> +#define TDX_FEATURES0_EXT BIT_ULL(39)
>
> #ifndef __ASSEMBLER__
>
> diff --git a/arch/x86/include/asm/tdx_global_metadata.h b/arch/x86/include/asm/tdx_global_metadata.h
> index 41150d546589..fe3fe91de71f 100644
> --- a/arch/x86/include/asm/tdx_global_metadata.h
> +++ b/arch/x86/include/asm/tdx_global_metadata.h
> @@ -44,12 +44,17 @@ struct tdx_sys_info_handoff {
> u16 module_hv;
> };
>
> +struct tdx_sys_info_ext {
> + bool ext_required;
> +};
> +
> struct tdx_sys_info {
> struct tdx_sys_info_version version;
> struct tdx_sys_info_features features;
> struct tdx_sys_info_tdmr tdmr;
> struct tdx_sys_info_td_ctrl td_ctrl;
> struct tdx_sys_info_td_conf td_conf;
> + struct tdx_sys_info_ext ext;
> };
>
> #endif
> diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c
> index 763c2d1b25d0..916a8906da10 100644
> --- a/arch/x86/virt/vmx/tdx/tdx.c
> +++ b/arch/x86/virt/vmx/tdx/tdx.c
> @@ -1181,6 +1181,30 @@ static __init int init_tdmrs(struct tdmr_info_list *tdmr_list)
> return 0;
> }
>
> +static __init int init_tdx_module_extensions(void)
> +{
> + int ret;
> +
> + if (!(tdx_sysinfo.features.tdx_features0 & TDX_FEATURES0_EXT))
> + return 0;
> +
> + ret = get_tdx_sys_info_ext(&tdx_sysinfo.ext);
> + if (ret)
> + return ret;
> +
> + /*
> + * ext_required indicates if any add-on features requiring TDX module
> + * extensions are configured via TDH.SYS.CONFIG. If none, skip the
> + * initialization.
> + */
> + if (!tdx_sysinfo.ext.ext_required)
> + return 0;
I'm slightly confused by the parlance introduced here. TDX_FEATURES0_EXT
indicates whether this tdx module supports extensions. And ext_required
aka 0x3100000000000001 is, as per td_scope_metadata.json: "Extended
Features Available Mask: indicates the extended user and system
features which are available for the TD." So aren't by definition all
add-on features extensions. How do you distinguish add-on which are
extensions and those which aren't? I think it's best if ext_required is
referred to as "ext_mask" or some such and not ext_required. That value
is not about what is required but rather what is available, no ?
<snip>
next prev parent reply other threads:[~2026-09-29 17:26 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-15 10:26 [PATCH v2 0/5] Enable TDX module extensions Xu Yilun
2026-09-15 10:26 ` [PATCH v2 1/5] x86/virt/tdx: Move TDH.SYS.CONFIG operations into a wrapper Xu Yilun
2026-09-15 20:45 ` Edgecombe, Rick P
2026-09-18 9:54 ` Xu Yilun
2026-09-22 7:09 ` Tony Lindgren
2026-09-15 10:26 ` [PATCH v2 2/5] x86/virt/tdx: Configure add-on features on TDX module init Xu Yilun
2026-09-15 20:54 ` Edgecombe, Rick P
2026-09-21 11:42 ` Xu Yilun
2026-09-22 14:48 ` Edgecombe, Rick P
2026-09-24 1:51 ` Xu Yilun
2026-09-16 3:23 ` Chao Gao
2026-09-18 9:56 ` Xu Yilun
2026-09-22 7:13 ` Tony Lindgren
2026-09-23 7:30 ` Xu Yilun
2026-09-23 7:59 ` Tony Lindgren
2026-09-24 1:33 ` Xu Yilun
2026-09-24 6:22 ` Tony Lindgren
2026-09-25 14:12 ` Nikolay Borisov
2026-09-15 10:26 ` [PATCH v2 3/5] x86/virt/tdx: Detect if the extensions initialization is required Xu Yilun
2026-09-15 21:14 ` Edgecombe, Rick P
2026-09-18 9:58 ` Xu Yilun
2026-09-28 21:06 ` Edgecombe, Rick P
2026-09-29 9:28 ` Xu Yilun
2026-09-29 16:33 ` Edgecombe, Rick P
2026-09-29 17:26 ` Nikolay Borisov [this message]
2026-09-15 10:26 ` [PATCH v2 4/5] x86/virt/tdx: Add extra memory to TDX module for the extensions Xu Yilun
2026-09-15 21:19 ` Edgecombe, Rick P
2026-09-16 7:40 ` Chao Gao
2026-09-18 10:06 ` Xu Yilun
2026-09-22 7:25 ` Tony Lindgren
2026-09-15 10:26 ` [PATCH v2 5/5] x86/virt/tdx: Make TDX module initialize " Xu Yilun
2026-09-15 22:09 ` [PATCH v2 0/5] Enable TDX module extensions 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=b88401eb-ebd8-41dd-8260-af3890886ca3@suse.com \
--to=nik.borisov@suse.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=rick.p.edgecombe@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 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®