Re: [PATCH v2 11/31] x86/virt/tdx: Make TDX Module initialize Extensions

[Huang, Kai]

On Wed, 2026-04-08 at 16:24 +0800, Xu Yilun wrote:
> On Wed, Apr 01, 2026 at 11:42:36AM +0000, Huang, Kai wrote:
> > On Tue, 2026-03-31 at 22:58 +0800, Xu Yilun wrote:
> > > > > +	/*
> > > > > +	 * ext_required == 0 means no need to call TDH.EXT.INIT, the Extensions
> > > > > +	 * are already working.
> > > > 
> > > > How does this scenario happen exactly? And why not check it above at the
> > > > beginning? Before the allocation, so it doesn't need to free.
> > > > 
> > > > Is there a scenario where the memory needs to be given, but the extension is
> > > > already inited?
> > > 
> > > mm.. you are right. It leads to something absurd.
> > > 
> > > I checked with TDX Module team again. The correct understanding is:
> > > 
> > >  - TDX_FEATURES0_EXT bit shows Extensions is supported.
> > >  - optional feature bits are selected on TDH_SYS_CONFIG
> > >  - If one of the optional feature (e.g. TDX CONNECT) requires Extention,
> > >    memory_pool_required_pages > 0 && ext_required == 1. Otherwise no
> > >    need to initialize Extension.
> > > 
> > > So yes, I should check memory_pool_required_pages && ext_required at the
> > > beginning.
> > 
> > My understanding is different:
> > 
> > Per spec, the 'EXT_REQUIRED' global metadata just means "Return true if the
> > TDH.EXT.INIT is required to be called", so I think, architecturally, it's
> 
> Maybe these text should be improved. They just literally tell how, so leads
> to our disagreement.
> 
> > possible that one particular feature only requires additional memory pool
> > but doesn't explicitly need to call TDH.EXT.INIT.  Or some feature may not
> > require any additional memory pool but needs TDH.EXT.INIT.
> 
> This is different from what I've been told by TDX Module team. Do you
> have a real setup like that?
> 
> My gut feeling also tells me there is little chance that:
> 
>  1. The Extensions is already working (cause no need to call
>     TDH.EXT.INIT) while we are still adding memory.
>  2. The Extensions could enable long running / hard-irq preemptible
>     flows with no memory consumption.

I don't think we need to guess here.  We need to understand what the
architecture behaviour is and then write code based on that.  If there's
anything not clear on architecture, we need to ask the module team to
clarify.

Back to the architecture behaviour, the spec "4.4 TDX Module Extension
Initialization" says:

  1. The host VMM configures the desired TDX features ...

  2. Based on the enabled features, the TDX Module checks whether a memory 
     pool is required and if so, calculates its required size.

  3. The host VMM reads MEMORY_POOL_REQUIRED_PAGES, the number of missing
     TDX Module’s memory pool pages, using TDH.SYS.RD.

  4. Once the TDX Module has been initialized (TDH.SYS.KEY.CONFIG was 
     called on all packages), the host VMM can call TDH.EXT.MEM.ADD  
     multiple times to add the required number of memory pages to the TDX
     Module’s memory pool.

  5. The host VMM reads EXT_REQUIRED, which indicates whether the TDX
     Module extension is required to be initialized, using TDH.SYS.RD.
     If required, the host VMM can then call TDH.EXT.INIT to initialize
     the TDX Module extension.

So to me it's clear that we need to do things in following:

  1. Opt-in ext features in TDH.SYS.CONFIG
  2. Read MEMORY_POOL_REQUIRED_PAGES and EXT_REQUIRED
  3. After TDH.SYS.KEY.CONFIG, initialize the module extension:
    a. If MEMORY_POOL_REQUIRED_PAGES is not zero, do TDH.EXT.MEM.ADD
    b. If EXT_REQUIRED is not zero, do TDH.EXT.INIT

To me there's no need to make any other assumption here.