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

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

On Fri, Aug 21, 2026 at 10:01:16PM +0000, Edgecombe, Rick P wrote:
> On Fri, 2026-08-21 at 11:29 +0800, Xu Yilun wrote:
> > The TDX architecture identifies some features that must be explicitly
> > enabled when the kernel supports them. 
> > 
> 
> It sounds like this is saying that TDX module is demanding that the kernel
> enable these features if it can. I think it's not true.

The TDX architecture identifies some features that are off by default
but can be enabled by the host during TDX module initialization or
update.

> 
> > These add-on features affect
> > existing TDX systems: they may change existing feature behavior, reserve
> > more memory, or impact TDX initialization performance.
> > 
> 
> What are you trying to get at by saying they affect existing TDX systems? It's
> important that if a new module gains these features, an upgrade *doesn't* affect
> existing TDX systems. Are you trying to say instead that they *would* affect
> existing systems, so they are add-ons?

Yes. Previously Xiaoyao asked "why only these bits are add-on features
while the rest in TDX_FEATURES01 are not" [1], so I added these words.

[1] https://lore.kernel.org/lkml/823bf577-51a1-4a8a-b240-ef4a0d5573be@intel.com/

> 
> >  The kernel must
> > enable these add-on features at boot or post-update time.
> > 
> > TDISP, DICE-based quoting and TD migration are among those add-on
> > features, as their SEAMCALL leaves depend on a SEAMCALL execution
> > context built by the TDX module extensions. On the other hand, the TDX
> > architecture doesn't allow the extensions to be initialized if none of
> > these features are enabled.
> > 
> 
> So we have add-ons features and extensions. Some add-on features depend on
> extensions. And also, the extensions can't be initialized if the add-on features
> are not enabled? I'm not sure what you are trying to get at. That the kernel
> doesn't have the option to blindly initialize all extensions?
> 
> >  Add support for configuring add-on features,
> > as the prerequisite for enabling the extensions.
> 
> I kinda know how this stuff works and I'm still struggling to understand what
> you are trying to say...

I just try to explain why the add-on feature configuration patch appears
in this extensions series, because it is the prerequisite for extensions
enabling.

From your comment below, seems we don't have to explain this
prerequisite here. Maybe I should delete this part.

> 
> I think optional features are pretty common pattern that will be generally
> understood. So the only thing that needs explanation is that some optional (or
> add-on) features need extra memory to save state, etc. But actually, this patch
> doesn't deal with this, just turning on optional features.
> 
> > 
> > The TDX module extends TDH.SYS.CONFIG and TDH.SYS.UPDATE with new bitmap
> > parameters to specify which add-on features to enable. 
> > 
> 
> Because some other VMM was passing garbage in r9?

I think yes. On version0, r9 is ignored meaning architecturally VMM is
OK to fill any value in r9.

> Hmm, how does this work with other features0 bits?
> Like for dynamic PAMT is a feature0 bit, but we pass it in
> r8. But for add-on features that use extensions we pass it in r9?

I feel this is historical baggage in the ABI design.

> Or do we pass
> all features0 bits in r9 for when using v1 of TDH.SYS.CONFIG? The docs say:
> 
>    If the requested version in RAX is 1 or higher, R9 specifies TDX Module
>    feature enabling flags, formatted similarly to TDX_FEATURES0, readable by
>    TDH.SYS.RD*. A bit may be set to 1 if the corresponding TDX_FEATURES0 bit is
>    1.

No, there are two more rows in the table to specify: 

According to SPEC, for other feature0 bits whose value is in TDX_FEATURES0,
they must be 0. for bits not in TDX_FEATURES0, they are ignored.

> 
> I wonder why they didn't just use the many reserved bits 63:17 of r8 for new
> features instead of this new seamcall version...

I guess they want to re-use TDX_FEATURES0, they don't want to make new
definition of every bit for each add-on feature. But let me check with
module team.

> 
> > The bitmap
> > uses the same feature bits as TDX_FEATURES0. Add a
> > get_tdx_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 extra bitmap to TDH.SYS.CONFIG helper.
> > 
> > The TDX module requires SEAMCALL leaf version 1 for TDH.SYS.CONFIG and
> > TDH.SYS.UPDATE when passing the new bitmap parameter. A previous
> > change [1] supports the versioned SEAMCALL leaves by adding a "version"
> > field in struct tdx_module_args. Set the version field to 1 if any bit
> > is set in this bitmap.
> > 
> > Compatible updates keep the reported features unchanged across updates,
> > so that existing TDX users can continue to operate without disruption.
> > To adhere to this
> > 
> 
> Compatible updates keep from disturbing the kernel. So the kernel shouldn't need
> to adhere to anything. Just say the kernel doesn't need to re-fetch it.

Good to me.

> 
> > , provide TDH.SYS.UPDATE with the same bitmap returned
> > by get_tdx_addon_features0(). This works because the module supported
> > feature bits are cached at boot and never refreshed after updates, so
> > the returned bitmap always matches the initial TDH.SYS.CONFIG input.
> 
>