Linux Confidential Computing Development
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: Xu Yilun <yilun.xu@linux.intel.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org
Cc: kas@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: Wed, 8 Jul 2026 11:03:14 -0700	[thread overview]
Message-ID: <e8aaca8c-6d88-490b-a3ae-c63a9e9a8b90@intel.com> (raw)
In-Reply-To: <20260708170330.83850-1-yilun.xu@linux.intel.com>

On 7/8/26 10:03, Xu Yilun wrote:
> +/*
> + * SEAMCALL leaf:
> + *
> + * Bit 15:0	Leaf number
> + * Bit 23:16	Version number
> + */
> +#define SEAMCALL_VERSION_MASK		GENMASK_U64(23, 16)
> +
>  static __always_inline u64 __seamcall_dirty_cache(sc_func_t func, u64 fn,
>  						  struct tdx_module_args *args)
>  {
> @@ -39,6 +48,7 @@ static __always_inline u64 __seamcall_dirty_cache(sc_func_t func, u64 fn,
>  	 */
>  	this_cpu_write(cache_state_incoherent, true);
>  
> +	FIELD_MODIFY(SEAMCALL_VERSION_MASK, &fn, args->version);
>  	return func(fn, args);
>  }

This is really looking fragmented and inconsistent.

What if someone *does* set the version bits in 'fn'? Also, if the "leaf
number" is just 16 bits, why is it a u64 in the API?

Additionally, look at this:

> /*
>  * Used in __tdcall*() to gather the input/output registers' values of the
>  * TDCALL instruction when requesting services from the TDX module. This is a
>  * software only structure and not part of the TDX module/VMM ABI
>  */
> struct tdx_module_args {

"version" doesn't fit this comment, does it? It's not a register.

If "fn" is just the 16-bit leaf number it should be a u16 everywhere.
Then there's no worry about the version number leaking in there
somewhere. The type can't even _carry_ the version number.

As a general rule, I dislike doing things in assembly that can be done
in C. But, in this case, we have some pretty darn simple assembly doing
a pretty simple job: marshaling data out of 'tdx_module_args' and in to
registers.

If we add a new argument to 'tdx_module_args' it seems like the most
consistent thing to do would be to extend the assembly to marshal it too.

We already have:

        /* Move Leaf ID to RAX */
        mov %rdi, %rax

and it wouldn't be rocket science to add two instructions to get
->version in to place:

	/* Leaf ABI version -> RAX[23:16]. Zero rest of RAX. */
	movzbl	TDX_MODULE_version(%rsi), %eax
	shl	$16, %eax
	/* Leaf number arg -> RAX[15:0]; Preserve [23:16]. */
	mov	%di, %ax

I don't *love* this. But, to be honest, I'd never even seen
FIELD_MODIFY() before.

Also, please double and triple check the assembly above. This does
depend pretty heavily on the rules around register naming and width, and
x86 is not exactly the most straightforward ISA in the world there.

I also wouldn't be shocked if there's a nicer way to do this that
someone else dreams up.

  reply	other threads:[~2026-07-08 18:03 UTC|newest]

Thread overview: 6+ 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 [this message]
2026-07-09 10:16   ` Xu Yilun
2026-07-10 16:21   ` Kiryl Shutsemau
2026-07-10 16:48     ` Dave Hansen
2026-07-10 15:56 ` Kiryl Shutsemau

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=e8aaca8c-6d88-490b-a3ae-c63a9e9a8b90@intel.com \
    --to=dave.hansen@intel.com \
    --cc=chao.gao@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=djbw@kernel.org \
    --cc=kas@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox