Re: [PATCH 01/15] x86/virt/tdx: Read global metadata for TDX Module Extensions

[Xu Yilun <yilun.xu@linux.intel.com>]

On Tue, May 26, 2026 at 11:05:48PM -0700, Sohil Mehta wrote:
> On 5/21/2026 8:41 PM, Xu Yilun wrote:
> > Add reading of the global metadata for TDX Module Extensions.
> > 
> > TDX Module Extensions is an add-on feature enumerated by TDX_FEATURES0.
> > But for the Module's integrity, Linux requires that all features that a
> > Module advertises must have a complete, valid set of metadata, and the
> > validation must succeed at core TDX initialization time.
> > 
> > Check TDX_FEATURES0 before reading these metadata. If a feature is
> > advertised, a failure in reading associated metadata causes the entire
> > TDX initialization to fail, otherwise skip.
> > 
> > Signed-off-by: Xu Yilun <yilun.xu@linux.intel.com>
> > ---
> >  arch/x86/include/asm/tdx_global_metadata.h  |  6 ++++++
> >  arch/x86/virt/vmx/tdx/tdx.h                 |  1 +
> >  arch/x86/virt/vmx/tdx/tdx_global_metadata.c | 16 ++++++++++++++++
> 
> The top comments in tdx_global_metadata.h and tdx_global_metadata.c say
> that these files are autogenerated. I believe the script lives outside
> the tree. Is there a plan to merge the script?

No, the plan of auto-generating is deprecated. Now we switch to manual
update.

> 
> The generated code is optimized for space instead of readability. Also,
> I see odd uncommented assignments u64 => u8/u16 all over the file. I am
> assuming the upper bits are expected to be zero.
> 
> The patch is hard to review without the script. Can you post a link to

Yes, it is. A new plan is to refactor the file in future.

> the updated script that led to this patch?
> 
> 
> >  3 files changed, 23 insertions(+)
> > 
> > diff --git a/arch/x86/include/asm/tdx_global_metadata.h b/arch/x86/include/asm/tdx_global_metadata.h
> > index 40689c8dc67e..533afe50a3f1 100644
> > --- a/arch/x86/include/asm/tdx_global_metadata.h
> > +++ b/arch/x86/include/asm/tdx_global_metadata.h
> > @@ -40,12 +40,18 @@ struct tdx_sys_info_td_conf {
> >  	u64 cpuid_config_values[128][2];
> >  };
> >  
> > +struct tdx_sys_info_ext {
> > +	u16 memory_pool_required_pages;
> > +	u8 ext_required;
> 
> The name ext_required seems like a boolean. It is also used like a
> boolean later.
> 	if (!tdx_sysinfo.ext.ext_required)
> 		return 0;
> 
> But, IIUC, is it actually a mask that lists any feature that needs

No it is just a bool about Extentions needs to be initialized or not.

> extensions to work correctly? If so, it would be good to give it a name
> that reflects its usage. Maybe:
> features_requiring_ext or something better
> 
> As Xiaoyao mentioned, the struct requires a better explanation in the
> commit log.

Will do. I also plan to change the patch organization: instead of the
old auto-generated patch splitting style, I will switch to a human-readable
style and fold these metadata readings directly into the patches that
actually use them (e.g., DPAMT and TDX Runtime Update).