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

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

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.

> 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?

>  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 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? 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? 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.

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...

> 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.

> , 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.