Re: [PATCH v2 03/17] x86/virt/tdx: Detect if the extensions initialization is required

[Edgecombe, Rick P]

On Thu, 2026-07-30 at 01:08 +0800, Xu Yilun wrote:
> > > But yes, a brief explaination of why we need special initialization is
> > > good to me: A global service environment should be built to provide
> > > some general context switching mechanism inside TDX module.
> > 
> > Wait are all extension seamcalls resumable? Couldn't there be one associated
> > with an extension that is not?
> 
> All extension SEAMCALLs must be preemptible and resumable.

My main issue is that I don't see why this need to be declared in a patch called
"Detect if the extensions initialization is required".

But nothing I can see in the TDX docs says something like the above. It may be
true from your reasoning, but I don't see what is gained by declaring it a hard
rule either.

>  If a SEAMCALL
> doesn't need the ability, it is not backed by an extension. Note an
> extension may only serve part of the functionalities of a feature, for
> example, for TDX Connect, only SPDM related SEAMCALLs are extension
> SEAMCALLs, others are not cause they have short or simple routines.
> 
> > We have so far explained extensions in terms of
> > the TDX module needing more memory for the optional features. So "extension"
> > probably be interpreted as "optional", not as enabling "preemptible"
> > seamcalls.
> 
> This is a long story and is explained in cover-letter. The need for extra
> memory is only a requirement to host, not the purpose for "extension".
> 
> Normal SEAMCALLs monopolize CPUs when execution. To prevent starving the
> host, SEAMCALL developers must count instructions at compile time,
> pre-define interrupt check-points and yield to host. This programming
> mode for TDX module is so complex that is hardly possible to handle
> complex tasks. As a result, TDX module had to push complexity into the
> host, such as by fragmenting a protocol setup service into several
> phases, let the host manage the overall flow and the SEAMCALLs only
> handle the secure parts which are short routines...  This makes the
> SEAMCALL ABIs trivial, losing their semantic meanings. While AMD only
> calls a TIO_DEV_CONNECT and let its co-processor manage the whole thing.
> 
> A preemptible SEAMCALL behaves like an OS task, so a specific SEAMCALL
> developer could easily handle a complex routine, without caring about
> starving the host. A general underlying service environment is taking
> care of the hardware interrupt response, the context switch...
> 
> So IMHO a normal SEAMCALL may be called 'resumable' to some extent, but
> it is definitely not 'preemptible', it voluntarily yields.

No, some check for pending interrupts and exit back to the host if it sees one.
They save their progress manually and Linux relies on this. So it's the same
from the host perspective. Pre-empted, save state, resume where you left off.

>  That's also
> why I think "preemptible SEAMCALLs" natually explain things than
> "extension SEAMCALLs"
> 
> [...]
> 
> > > ----8<----
> > > 
> > >   TDX adds a new class of SEAMCALLs which are preemptible and can
> > > cooperate
> > >   with the host scheduling. 
> > 
> > But these are not new is the point. Look for TDX_INTERRUPTED_RESUMABLE in
> > Linux
> > and TDX source.
> 
> From host perspective, extension SEAMCALLs are just like normal
> 'resumable' SEAMCALLs. But the mechanism is new, and we have to explain
> the differences, otherwise there is no justification why we introduce
> the extensions.

Sure. People are not saying to skip explaining what is new. People are saying
that what you are saying is new (pre-emptible, resumable), isn't new.

> 
> > 
> > > Some features like TDISP, DICE-based quoting
> > >   rely on these preemptible SEAMCALLs to implement higher order security
> > >   protocols with simple ABIs. To enable preemptible SEAMCALLs, a global
> > >   service environment, called TDX module extensions, must first be
> > >   initialized.
> > 
> > Why are we even talking about this in a patch that reads the metadata. Is it
> > necessary?
> 
> OK, I can drop the introduction of the context here, it is not
> necessary. The cover-letter has the detailed explanation.
> 
> But should we still add the introduction in patch 5 ("x86/virt/tdx: Make
> TDX module initialize the extensions")?

Maybe it fits better in patch 4, because it is adding memory to save the state.
But I think we shouldn't dwell too much on the internal details all over the
logs.

I think it's good context to help reason about what is going on. But the
important parts are that these extensions are optional and need more memory to
save state for their interruptible resumable operations.