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

On Mon, Jul 27, 2026 at 05:56:31PM +0000, Edgecombe, Rick P wrote:
> On Mon, 2026-07-27 at 20:38 +0800, Xu Yilun wrote:
> > > This is not true. There are some normal (non-extension) SEAMCALLs also are
> > > preemptible and resumable. For example,
> > > 
> > > - TDH.PHYMEM.CACHE.WB
> > > - TDH.SYS.DISABLE
> > > - TDH.MEM.SEPT.ADD with version 1
> > 
> > No they are not preemptible and resumable. They just intentionally
> > yield and don't have a generic way to save/resume their context. You
> > can't rely on that to implement complex tasks in TDX module considering
> > the complexity. That's the main reason why TDX module extensions are
> > needed.
> 
> We have RESUMABLE seamcalls today. They are guaranteed to save state and make
> forward progress. Xiaoyao is right, this is not a new concept from the VMM side.

OK. Let me de-emphasize resumable.

And I'm thinking of how to stop explaining new terms again and again,
extension SEAMCALL is the one. I'm not sure if calling it "preemptible
SEAMCALLs" helps, or is it still a new term?

> But also why highlight this for the patch here. Are you trying to explain why
> extension initialization needs some special step?

I was following the suggestion [1] of explaining the context in general.
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.

[1]: https://lore.kernel.org/all/[email protected]/

Refactored the first paragraph:

----8<----

  TDX adds a new class of SEAMCALLs which are preemptible and can cooperate
  with the host scheduling. 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.

  ...