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

[Xu Yilun]

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

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