Re: [PATCH v2 08/31] x86/virt/tdx: Configure TDX Module with optional TDX Connect feature

["Huang, Kai" <kai.huang@intel.com>]

On Wed, 2026-04-01 at 23:53 +0000, Edgecombe, Rick P wrote:
> On Wed, 2026-04-01 at 23:42 +0000, Huang, Kai wrote:
> > Maybe a more generic comment:
> > 
> > I don't quite like hard-coding opt-in TDX_FEATURES0_TDXCONNECT inside
> > config_tdx_module(), especially currently we just unconditionally opt it in
> > if the module support this feature.
> > 
> > Initializing TDX Connect (and other features via TDX Module Extensions)
> > consumes more memory.  It would be better if we can choose to opt-in when
> > the kernel has enabled TDX Connect (or any other feature via TDX module
> > Extensions) in the Kconfig.
> 
> Better how? TDX uses a lot of memory. There are many possible optimizations to
> reduce this. Why focus on this one? Do we think any TDX users would actually
> reconfigure there kernel for this reason?
> 
> I mean, I don't actually know how much memory this is, but to me the reasoning
> doesn't seem in balance with the wider TDX situation.

In another patch, Yilun said:

  For now, TDX Module Extensions consume relatively large amount of
  memory (~50MB).

Distros tend to enable all I assume.  I guess the CSPs tend to enable all as
well, but I am not sure whether CSPs can also choose to only enable basic
TDX w/o other features like runtime update, TDX Connect etc, depending on
how they want to "sell" TDX VMs.

E.g., I assume a TD without GPU passthrough could be cheaper the one which
has, right?  Can the CSPs host such TDs on dedicated machine pools?  Can
they choose to disable TDX Connect on these machines?

They might not care about losing ~50M memory, though, but that's a different
story, and it could be more in the future.

My thinking is, this series actually introduced a new "TDX_CONNNECT"
Kconfig, so why not only consume the memory when it's on?

At last, just my 2cents, I kinda overall don't agree we always assume
"everything will be on" but neglect avoiding unnecessary code/cost that is
not reachable when some option is off.  That would defeat the purpose of
having Kconfig option.