Re: [PATCH v5] x86/virt/tdx: Formalize SEAMCALL leaf version encoding support

[Xu Yilun]

On Tue, Sep 08, 2026 at 02:26:39PM +0800, Binbin Wu wrote:
> On 9/1/2026 6:54 PM, Xu Yilun wrote:
> > The TDX architecture includes a syscall-like ABI for OSes to communicate
> > with SEAM mode software. This ABI has the concept of a "leaf". Each leaf
> > is roughly analogous to a Linux syscall: it has a set of register
> > arguments and does one logical thing like adding a page of memory to a
> > VM or running a VM. The TDX architecture refers to this interface
> > function as a "SEAMCALL leaf".
> > 
> > Just like syscalls, the TDX architecture wants to evolve the ABI to
> > extend functionality while keeping compatibility. But unlike syscalls,
> > which do this by picking a totally new syscall number, the ABI encodes
> > the "version" number directly into the bits of a register argument. So
> > instead of openatN being whatever the next free number is, the SEAMCALL
> > leaf number and version number are encoded into certain bits in how the
> > RAX register is defined in the ABI.
> > 
> > In Linux, several seamcall*() wrappers have been introduced to invoke
> > SEAMCALL leafs. They all take a u64 "fn" argument for the leaf number
> > which eventually get set in the register. As above, the version number
> > lives in the same register as the leaf number. So callers that want to
> > select a specific version of the leaf, can jam it in the right place in
> > the register by passing it in the "fn" argument.
> 
> Do you think it's worth explaining how callers determine the versions
> supported by the TDX module,

Yeah I described this in v4 [1]. Generally it is "selecting the minimum
workable version number for the required functionality".

But I feel it distracts people from the problem this patch wants to
solve, so I removed it. This patch actually involves no runtime version
selection. The future change for TDH.SYS.CONFIG does. Better we add the
explaination in that patch?

[1]: https://lore.kernel.org/all/20260804085054.190847-1-yilun.xu@xxxxxxxxxxxxxxx/

> and what happens if the specified version
> is not supported by the TDX module?

I think it should not happen. This means the kernel is trying to enable a
functionality that the module doesn't support. Either there is a problem
on feature enumeration, or people are using a deprecated module. Anyway
don't runtime check if a SEAMCALL version is supported.

Thanks,
Yilun