[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <8aa96131-c719-411b-92c2-1c3b121d89e6@intel.com>
Date: Thu, 29 Jan 2026 08:59:14 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Chao Gao <chao.gao@...el.com>
Cc: linux-coco@...ts.linux.dev, linux-kernel@...r.kernel.org,
kvm@...r.kernel.org, x86@...nel.org, reinette.chatre@...el.com,
ira.weiny@...el.com, kai.huang@...el.com, dan.j.williams@...el.com,
yilun.xu@...ux.intel.com, sagis@...gle.com, vannapurve@...gle.com,
paulmck@...nel.org, nik.borisov@...e.com, zhenzhong.duan@...el.com,
seanjc@...gle.com, rick.p.edgecombe@...el.com, kas@...nel.org,
dave.hansen@...ux.intel.com, vishal.l.verma@...el.com,
Farrah Chen <farrah.chen@...el.com>, Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH v3 06/26] x86/virt/tdx: Prepare to support P-SEAMLDR
SEAMCALLs
On 1/29/26 06:55, Chao Gao wrote:
> On Wed, Jan 28, 2026 at 03:03:14PM -0800, Dave Hansen wrote:
...
> Thanks. This is much clearer than my version.
>
> One tiny nit: NP-SEAMLDR isn't SEAM mode software. It is an authenticated code
> module (ACM).
Ahhh, thanks for the correction!
>> Then do this part:
>>
>>> P-SEAMLDR SEAMCALLs differ from SEAMCALLs of the TDX module in terms of
>>> error codes and the handling of the current VMCS.
>> Except I don't even know how the TDX module handles the current VMCS.
>> That probably needs to be in there. Or, it should be brought up in the
>> patch itself that implements this. Or, uplifted to the cover letter.
>
> My logic was:
>
> 1. The kernel communicates with P-SEAMLDR via SEAMCALL, just like with the TDX
> Module.
> 2. But P-SEAMLDR SEAMCALLs and TDX Module SEAMCALLs are slightly different.
>
> So we need some tweaks to the low-level helpers to add separate wrappers for
> P-SEAMLDR SEAMCALLs.
>
> To me, without mentioning #2, these tweaks in this patch (for separate wrappers
> in the next patch) aren't justified.
My objection is that you talk about the VMCS handling in here but
there's no actual VMCS handling. This is the changelog for patch 06/26,
not 07/26.
Don't talk about the VMCS handling here. When you do, make sure you give
enough background.
>>> static __always_inline u64 sc_retry(sc_func_t func, u64 fn,
>>> struct tdx_module_args *args)
>>> {
>>> + u64 retry_code = TDX_RND_NO_ENTROPY;
>>> int retry = RDRAND_RETRY_LOOPS;
>>> u64 ret;
>>>
>>> + if (unlikely(is_seamldr_call(fn)))
>>> + retry_code = SEAMLDR_RND_NO_ENTROPY;
>>
>> (un)likey() has two uses:
>>
>> 1. It's in performance critical code and compilers have been
>> demonstrated to be generating bad code.
>> 2. It's in code where it's not obvious what the fast path is
>> and (un)likey() makes the code more readable.
>>
>> Which one is this?
>
> I think #2 although I am happy to drop "unlikely".
But why does it *MATTER*? Is it important to understand that SEAMLDR
calls are rarer than TDX module calls?
Powered by blists - more mailing lists