From: Kiryl Shutsemau <kas@kernel.org>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Xu Yilun <yilun.xu@linux.intel.com>,
x86@kernel.org, linux-kernel@vger.kernel.org,
rick.p.edgecombe@intel.com, dave.hansen@linux.intel.com,
yilun.xu@intel.com, chao.gao@intel.com, djbw@kernel.org,
linux-coco@lists.linux.dev, peter.fang@intel.com,
xiaoyao.li@intel.com
Subject: Re: [PATCH v2] x86/virt/tdx: Formalize SEAMCALL version encoding support
Date: Mon, 13 Jul 2026 10:40:36 +0100 [thread overview]
Message-ID: <alSxrcseFHNrttoy@thinkstation> (raw)
In-Reply-To: <f8ef7a94-7824-4d1f-899a-60a0fbd2e2f7@intel.com>
On Fri, Jul 10, 2026 at 09:48:22AM -0700, Dave Hansen wrote:
> On 7/10/26 09:21, Kiryl Shutsemau wrote:
> > The version is not a register operand, it is part of the function
> > number.
>
> I'm not sure why that's important.
>
> Sure, the arg structure is all full registers now. But it's not even all
> the registers because RAX isn't there. So let's say we made the data
> structure smarter:
>
> struct tdx_module_args {
> union {
> u64 rax;
> struct {
> u16 function_nr;
> u8 version
> u8 padding0;
> u32 flags;
> };
> };
> u64 rcx;
> u64 rdx;
> ...
> }
This union doesn't match the ABI it is supposed to represent.
RAX is:
15:0 Leaf number
23:16 Version number
24 INTERRUPT_MODE
62:25 Reserved
63 P-SEAMLDR select
In your layout INTERRUPT_MODE ends up somewhere in padding0 and the
P-SEAMLDR bit is BIT(31) of 'flags'. Nothing lines up with the spec.
To describe the format properly the struct would need bitfields, and we
generally discourage bitfields for ABI-defined layouts. Without
bitfields it degrades into masks and shifts on a u64 -- which is
exactly what composing 'fn' with a macro is. The union doesn't add
anything on top of that, it only hides where the bits are.
>
> All of the:
>
> struct tdx_module_args args = {};
>
> instances would default to version=0. It would take a one-liner to get
> bit 63 set:
>
> static int seamldr_call(u64 fn, struct tdx_module_args *args)
> {
> ...
> + args->flags |= SEAMLDR_BIT;
> guard(raw_spinlock)(&seamldr_lock);
> return seamcall_prerr(fn, args);
> }
>
> The truth of the matter is that 'fn' *IS* the RAX from the TDX ABI.
> We're carrying it around the kernel in that format, and it just doesn't
> work very well.
>
> The alternative is to carry the logical pieces of RAX around the kernel
> and them assemble RAX out of them in one (or very few) places. *Not* to
> build RAX in the TDX module ABI early far from the TDX module ABI layer
> itself.
I don't see what delaying the assembly buys us.
The SEAMCALL helper is where we decide what we want from the call: the
leaf, the version, the operands. Nothing below it adds information --
sc_retry() and __seamcall_dirty_cache() only retry on entropy failure
and track cache state. There is no layer further down that is in a
better position to compose RAX than the helper itself.
And it is not "far from the TDX module ABI layer". The tdh_*() helpers
are the C representation of the ABI functions. They are the ABI layer.
We also don't carry the pieces "around the kernel" today. The
composition already happens in exactly one place -- a macro next to the
leaf defines. Call sites don't open-code shifts.
That said, I'm okay with RAX living in the struct as a plain u64
instead of a separate 'fn' argument, if you prefer the structure to
carry all the registers. But its composition should stay early, in the
helper, where the decisions about the call are made:
args.rax = TDH_VP_INIT | SEAMCALL_LEAF_VER(1);
--
Kiryl Shutsemau / Kirill A. Shutemov
next prev parent reply other threads:[~2026-07-13 9:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-08 17:03 [PATCH v2] x86/virt/tdx: Formalize SEAMCALL version encoding support Xu Yilun
2026-07-08 18:03 ` Dave Hansen
2026-07-09 10:16 ` Xu Yilun
2026-07-10 16:21 ` Kiryl Shutsemau
2026-07-10 16:48 ` Dave Hansen
2026-07-13 9:40 ` Kiryl Shutsemau [this message]
2026-07-10 15:56 ` Kiryl Shutsemau
2026-07-13 9:21 ` Xu Yilun
2026-07-13 11:38 ` Kiryl Shutsemau
2026-07-14 11:18 ` Xu Yilun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alSxrcseFHNrttoy@thinkstation \
--to=kas@kernel.org \
--cc=chao.gao@intel.com \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=djbw@kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=peter.fang@intel.com \
--cc=rick.p.edgecombe@intel.com \
--cc=x86@kernel.org \
--cc=xiaoyao.li@intel.com \
--cc=yilun.xu@intel.com \
--cc=yilun.xu@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.