From: Chao Gao <chao.gao@intel.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: <kvm@vger.kernel.org>, <linux-coco@lists.linux.dev>,
<linux-kernel@vger.kernel.org>, <x86@kernel.org>,
<binbin.wu@linux.intel.com>, <dave.hansen@linux.intel.com>,
<djbw@kernel.org>, <ira.weiny@intel.com>, <kai.huang@intel.com>,
<kas@kernel.org>, <nik.borisov@suse.com>, <paulmck@kernel.org>,
<pbonzini@redhat.com>, <reinette.chatre@intel.com>,
<rick.p.edgecombe@intel.com>, <sagis@google.com>,
<seanjc@google.com>, <tony.lindgren@linux.intel.com>,
<vannapurve@google.com>, <vishal.l.verma@intel.com>,
<yilun.xu@linux.intel.com>, <xiaoyao.li@intel.com>,
<yan.y.zhao@intel.com>, Thomas Gleixner <tglx@kernel.org>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH v8 17/21] x86/virt/seamldr: Abort updates on failure
Date: Fri, 8 May 2026 17:16:57 +0800 [thread overview]
Message-ID: <af2qCU4mH5BV188O@intel.com> (raw)
In-Reply-To: <fc27ad0e-fceb-4eed-bb1c-dbfb5b913bf6@intel.com>
On Thu, Apr 30, 2026 at 01:06:38PM -0700, Dave Hansen wrote:
>I don't like how this is being done.
>
> 1. Introduce this do{}while() loop
> 2. Do 20 other patches
> 3. Introduce a thing that can make it change
> 4. Change the fundamental flow of the loop, to fix #3
>
>I'd much rather have:
>
> 1. Introduce this do{}while() loop
> 2. Tweak fundamental flow of the loop from the last patch when I can
> remember it. Allude to future failures.
> 3. Do 20 other patches
> 4. Introduce a thing that uses #2
OK, that makes sense. I'll reorder the series so this patch comes immediately
after the skeleton patch.
>
>
>> diff --git a/arch/x86/virt/vmx/tdx/seamldr.c b/arch/x86/virt/vmx/tdx/seamldr.c
>> index c81b26c4bac1..9b8f571eb03f 100644
>> --- a/arch/x86/virt/vmx/tdx/seamldr.c
>> +++ b/arch/x86/virt/vmx/tdx/seamldr.c
>> @@ -220,6 +220,7 @@ enum module_update_state {
>> static struct {
>> enum module_update_state state;
>> int thread_ack;
>> + bool failed;
>> /*
>> * Protect update_data. Raw spinlock as it will be acquired from
>> * interrupt-disabled contexts.
>> @@ -284,12 +285,15 @@ static int do_seamldr_install_module(void *seamldr_params)
>> break;
>> }
>>
>> - ack_state();
>> + if (ret)
>> + WRITE_ONCE(update_data.failed, true);
>> + else
>> + ack_state();
>> } else {
>> touch_nmi_watchdog();
>> rcu_momentary_eqs();
>> }
>
>I don't like how this is turning out either. I don't like all the nested
>conditions or ack_state() that hides its mucking with update data while
>its caller mucks with it directly. It's just all hacked together.
>
>Defer all of the acking, and *failed* acking to the ack_state() helper.
OK. I'll fold both normal and failed acking into ack_state().
>
>Also, I'm kinda peeved that you copied and pasted the
>touch_nmi_watchdog()/rcu_momentary_eqs() bits and none of the comments.
>This is a rather subtle use of both. If you want this to be a normal
>"spinning in stop machine" idiom, then create a helper and put the
>comments there.
Those two calls were added in stop_machine() to improve debuggability.
The issue they address is that a stop_machine() callback can hang on one
CPU. Without touch_nmi_watchdog() and rcu_momentary_eqs(), the other CPUs
that are merely spinning in the wait loop can also report hard lockup and
RCU stall warnings, which obscures the actual stuck CPU.
I agree that this behavior makes sense in stop_machine() as common
infrastructure. But this update path does not take an arbitrary callback
function, so that that debuggability is not strictly necessary here. I'll
drop those calls from this path unless there is an objection.
>
>Also, this is a case where:
>
> do {
> cpu_relax();
> newstate = READ_ONCE(update_data.state);
>
> if (newstate == curstate) {
> // can cpu_relax() just go in here??
> touch_nmi_watchdog();
> rcu_momentary_eqs();
> continue;
> }
>
> switch() {
> // state changing here
> }
> } while (...);
>
>is a much more sane setup. You're not paying the if() indentation cost
>for the entire state transition block. You're also putting the "shut up
>the warnings" code out of the way where you can forget about it.
>
Agreed. Will do.
next prev parent reply other threads:[~2026-05-08 9:17 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260427152854.101171-1-chao.gao@intel.com>
[not found] ` <20260427152854.101171-8-chao.gao@intel.com>
[not found] ` <06682111-2b63-444e-a431-b8dd0db2b0ab@intel.com>
2026-05-06 2:35 ` [PATCH v8 07/21] coco/tdx-host: Implement firmware upload sysfs ABI for TDX module updates Chao Gao
[not found] ` <20260427152854.101171-11-chao.gao@intel.com>
[not found] ` <0523b07b-2df2-4cf4-bf98-6efe01780698@intel.com>
2026-05-06 2:56 ` [PATCH v8 10/21] x86/virt/seamldr: Shut down the current TDX module Chao Gao
2026-05-06 20:49 ` Dave Hansen
[not found] ` <20260427152854.101171-12-chao.gao@intel.com>
[not found] ` <20f2d821-bfa6-4db2-a968-b5455c7b5007@intel.com>
2026-05-06 6:21 ` [PATCH v8 11/21] x86/virt/tdx: Reset software states during TDX module shutdown Chao Gao
[not found] ` <20260427152854.101171-16-chao.gao@intel.com>
[not found] ` <28be5180-ff74-4e4d-b392-7ba7a9b4c1c0@intel.com>
2026-05-06 12:51 ` [PATCH v8 15/21] x86/virt/tdx: Refresh TDX module version after update Chao Gao
[not found] ` <20260427152854.101171-10-chao.gao@intel.com>
[not found] ` <5dc70847-332d-496f-b0ab-03323eff7118@intel.com>
2026-05-06 13:00 ` [PATCH v8 09/21] x86/virt/seamldr: Introduce skeleton for TDX module updates Chao Gao
2026-05-06 20:43 ` Dave Hansen
[not found] ` <20260427152854.101171-9-chao.gao@intel.com>
[not found] ` <a52c4701-c99d-48d5-9b63-8eb1c0e589f0@intel.com>
2026-05-07 13:19 ` [PATCH v8 08/21] x86/virt/seamldr: Allocate and populate a module update request Chao Gao
2026-05-08 16:48 ` Dave Hansen
[not found] ` <20260427152854.101171-18-chao.gao@intel.com>
[not found] ` <fc27ad0e-fceb-4eed-bb1c-dbfb5b913bf6@intel.com>
2026-05-08 9:16 ` Chao Gao [this message]
[not found] ` <20260427152854.101171-19-chao.gao@intel.com>
[not found] ` <abd48a30-8d51-4a86-b662-b09afb567dc5@intel.com>
2026-05-08 9:50 ` [PATCH v8 18/21] coco/tdx-host: Don't expose P-SEAMLDR features on CPUs with erratum Chao Gao
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=af2qCU4mH5BV188O@intel.com \
--to=chao.gao@intel.com \
--cc=binbin.wu@linux.intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=djbw@kernel.org \
--cc=hpa@zytor.com \
--cc=ira.weiny@intel.com \
--cc=kai.huang@intel.com \
--cc=kas@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=nik.borisov@suse.com \
--cc=paulmck@kernel.org \
--cc=pbonzini@redhat.com \
--cc=reinette.chatre@intel.com \
--cc=rick.p.edgecombe@intel.com \
--cc=sagis@google.com \
--cc=seanjc@google.com \
--cc=tglx@kernel.org \
--cc=tony.lindgren@linux.intel.com \
--cc=vannapurve@google.com \
--cc=vishal.l.verma@intel.com \
--cc=x86@kernel.org \
--cc=xiaoyao.li@intel.com \
--cc=yan.y.zhao@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