Re: [PATCH v3 2/6] x86/virt/tdx: Configure add-on features on TDX module init

["Edgecombe, Rick P" <rick.p.edgecombe@intel.com>]

On Tue, 2026-10-06 at 01:41 +0800, Xu Yilun wrote:
> The TDX architecture identifies some features that are off by default
> but can be enabled by the host during TDX module initialization. They
> are classified as add-on features because enabling them affects existing
> TDX systems: they may change existing feature behavior, or reserve more
> memory.
> 
> The TDX module extends TDH.SYS.CONFIG with a new register argument to
> specify which add-on features to enable. This new argument is a bitmap
> that uses the same feature bits as TDX_FEATURES0. Note that Dynamic PAMT
> is an exception: although it is an add-on feature, it is controlled via
> a legacy, dedicated register argument [1].
> 
> The kernel needs to enable these add-on features when it supports them.

I made a similar comment on v1:
https://lore.kernel.org/lkml/41f5a558ca67e2895fcb114c418f0e453e933974.camel@intel.com/

It is up to the kernel to decide if it wants to enable these features, when it
supports them. The sentence sounds like there is some hard requirement to enable
them when possible. I think the reasons to enable them based solely on available
support could be:
 1. They don't take significantly more memory or CPU resources, and limiting
possible configs reduces kernel complexity.
 2. It would be rare that people don't want them on.

Maybe we tweak this to be?

Despite that these features can be add-ons due to introducing some overhead to
TDX runtime, the impact of the first features will be low enough to pursue a
simple approach of just enabling them when supported. If a feature with a very
high overhead appears in the future, this can be revisited.

> Add a get_tdx_usable_addon_features0() helper to return the bitmap of
> the add-on features that the module & kernel both support. Initially,
> this helper returns 0. It will be updated to return specific feature
> bits as full kernel support lands. Pass this bitmap as an argument to
> TDH.SYS.CONFIG.
> 
> The TDX module requires SEAMCALL leaf version 1 for TDH.SYS.CONFIG when
> passing the new bitmap argument. A previous change [2] supports the
> versioned SEAMCALL leafs by adding a "version" field in
> struct tdx_module_args. Set the version field to 1 if the new bitmap
> argument is used to enable any add-on feature, otherwise keep the
> version as 0. This retains backward compatibility with older modules
> that don't recognize version 1.
> 
> Signed-off-by: Xu Yilun <yilun.xu@linux.intel.com>
> Reviewed-by: Tony Lindgren <tony.lindgren@linux.intel.com>
> Reviewed-by: Nikolay Borisov <nik.borisov@suse.com>
> Link: https://lore.kernel.org/all/20260904215841.303070-10-rick.p.edgecombe@intel.com/ # [1]
> Link: https://lore.kernel.org/all/20260921-seamcall-version-v7-1-cf05fe76b467@linux.intel.com/ # [2]

With the log nit,

Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com>

> ---
> v3:
>  - Update the stale changlog for bitmap arg of the wrapper (Chao)
>  - s/get_tdx_addon_features0()/get_tdx_usable_addon_features0() (Tony)
>  - Collect Reviewed-by tags
> 
> v2:
>  - Don't pass addon_features0 parameter around, get it in the wrappers
>   (Dave)
>  - Remove TDH.SYS.UPDATE wrapper (Dave & Rick)
>  - Drop the changelog section explaining why add-on feature enabling is
>    needed in this series, as it is a generally understood pattern (Rick)
>  - Add a note in the changelog that Dynamic PAMT is not enabled via the
>    new bitmap argument (Rick)
>  - Add __init tag for get_tdx_addon_features0() (AI nitpicker)
> 
> v1:
>  - Use tdx_module_args.version to assign SEAMCALL leaf versions (Dave)
>  - Remove DICE specific descriptions (Rick)
>  - Remove the global var tdx_addon_features0 (Chao)
>  - Add a Macro to collect kernel supported add-on feature bits (Rick)
>  - Changelog & code comments change
> ---
>  arch/x86/virt/vmx/tdx/tdx.c | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c
> index b099aa4056f5..f08278a47aff 100644
> --- a/arch/x86/virt/vmx/tdx/tdx.c
> +++ b/arch/x86/virt/vmx/tdx/tdx.c
> @@ -1042,9 +1042,19 @@ struct tdmr_info_pa_array {
>  	DECLARE_FLEX_ARRAY(u64, phys);
>  };
>  
> +/* List all kernel-supported add-on features0 bits here */
> +#define TDX_KERNEL_SUPPORTED_ADDON_FEATURES0	(0)
> +
> +static __init u64 get_tdx_usable_addon_features0(void)
> +{
> +	return tdx_sysinfo.features.tdx_features0 &
> +		TDX_KERNEL_SUPPORTED_ADDON_FEATURES0;
> +}
> +
>  static __init int tdx_sys_config(struct tdmr_info_pa_array *tdmr_pa_array,
>  				 unsigned int nr_tdmr_pa, u64 global_keyid)
>  {
> +	u64 addon_features0 = get_tdx_usable_addon_features0();
>  	struct tdx_module_args args = {
>  		.rcx = __pa(tdmr_pa_array),
>  		.rdx = nr_tdmr_pa,
> @@ -1056,6 +1066,15 @@ static __init int tdx_sys_config(struct tdmr_info_pa_array *tdmr_pa_array,
>  		args.r8 |= TDX_SYS_CONFIG_DYNAMIC_PAMT;
>  	}
>  
> +	/*
> +	 * Use SEAMCALL version 1 that supports add-on features if any are
> +	 * requested. Otherwise use version 0 for backward compatibility.
> +	 */
> +	if (addon_features0) {
> +		args.r9 = addon_features0;
> +		args.version = 1;

This is a slightly silly pattern:
args.r9 = 0;
if (addon_features0 != 0)
	args.r9 = addon_features0;

...could just be:
args.r9 = addon_features0;

It could actually set args.version a similar branchless way.

But I think the version in this patch is super obvious about what is happening
and has a nice place for the comment. And this is extremely far from a
performance critical path.


> +	}
> +
>  	return seamcall_prerr(TDH_SYS_CONFIG, &args);
>  }
>  
>