Re: [PATCH v5 04/22] x86/virt/seamldr: Introduce a wrapper for P-SEAMLDR SEAMCALLs

From: Chao Gao

Date: Wed Mar 18 2026 - 05:40:50 EST


On Wed, Mar 18, 2026 at 03:13:06PM +0800, Xiaoyao Li wrote:
>On 3/15/2026 9:58 PM, Chao Gao wrote:
>> The TDX architecture uses the "SEAMCALL" instruction to communicate with
>> SEAM mode software. Right now, the only SEAM mode software that the kernel
>> communicates with is the TDX module. But, there is actually another
>> component that runs in SEAM mode but it is separate from the TDX module:
>> the persistent SEAM loader or "P-SEAMLDR". Right now, the only component
>> that communicates with it is the BIOS which loads the TDX module itself at
>> boot. But, to support updating the TDX module, the kernel now needs to be
>> able to talk to it.
>>
>> P-SEAMLDR SEAMCALLs differ from TDX module SEAMCALLs in areas such as
>> concurrency requirements. Add a P-SEAMLDR wrapper to handle these
>> differences and prepare for implementing concrete functions.
>>
>> Note that unlike P-SEAMLDR, there is also a non-persistent SEAM loader
>> ("NP-SEAMLDR"). This is an authenticated code module (ACM) that is not
>> callable at runtime. Only BIOS launches it to load P-SEAMLDR at boot;
>> the kernel does not need to interact with it for runtime update.
>>
>> For details of P-SEAMLDR SEAMCALLs, see Intel® Trust Domain CPU
>> Architectural Extensions, Revision 343754-002, Chapter 2.3 "INSTRUCTION
>> SET REFERENCE".
>
>SDM started to contain SEAMCALL definitions. How about just dropping this
>paragraph to avoid people from reading the old doc?

I didn't realize that. Thanks for the information.

But I don't think this is a stale reference. The SDM description is high-level
and points to the same spec for details:

The details of such transitions are specified in the Intel® Trust Domain CPU
Architectural Extensions.

>
>...
>
>> +static __maybe_unused int seamldr_call(u64 fn, struct tdx_module_args *args)
>> +{
>> + guard(raw_spinlock)(&seamldr_lock);
>> + return seamcall_prerr(fn, args);
>
>How about adding the reason of why choosing seamcall_prerr() instead of
>seamcall_prerr_ret() in the changelog?

Sure. Will add:

Use seamcall_prerr() (not '_ret') because current P-SEAMLDR calls do not use
any output registers other than RAX.