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

[Binbin Wu <binbin.wu@linux.intel.com>]

On 9/8/2026 5:43 PM, Xu Yilun wrote:
> 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?

It's OK for me.

I was wondering how did VMM know which version was supported.
Now I know It's based on the feature enumeration.

> 
> [1]: https://lore.kernel.org/all/20260804085054.190847-1-yilun.xu@linux.intel.com/
> 
>> 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