From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
To: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Gao, Chao" <chao.gao@intel.com>,
"x86@kernel.org" <x86@kernel.org>
Cc: "Huang, Kai" <kai.huang@intel.com>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"tony.lindgren@linux.intel.com" <tony.lindgren@linux.intel.com>,
"binbin.wu@linux.intel.com" <binbin.wu@linux.intel.com>,
"seanjc@google.com" <seanjc@google.com>,
"Weiny, Ira" <ira.weiny@intel.com>,
"Chatre, Reinette" <reinette.chatre@intel.com>,
"Verma, Vishal L" <vishal.l.verma@intel.com>,
"nik.borisov@suse.com" <nik.borisov@suse.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"kas@kernel.org" <kas@kernel.org>,
"Annapurve, Vishal" <vannapurve@google.com>,
"sagis@google.com" <sagis@google.com>,
"Duan, Zhenzhong" <zhenzhong.duan@intel.com>,
"tglx@kernel.org" <tglx@kernel.org>,
"paulmck@kernel.org" <paulmck@kernel.org>,
"hpa@zytor.com" <hpa@zytor.com>, "bp@alien8.de" <bp@alien8.de>,
"yilun.xu@linux.intel.com" <yilun.xu@linux.intel.com>,
"Williams, Dan J" <dan.j.williams@intel.com>
Subject: Re: [PATCH v4 11/24] x86/virt/seamldr: Introduce skeleton for TDX Module updates
Date: Thu, 12 Mar 2026 02:00:20 +0000 [thread overview]
Message-ID: <daa8080e1195f586af331dcf31ee5239c4ecbd15.camel@intel.com> (raw)
In-Reply-To: <20260212143606.534586-12-chao.gao@intel.com>
On Thu, 2026-02-12 at 06:35 -0800, Chao Gao wrote:
> TDX Module updates require careful synchronization with other TDX
> operations on the host. During updates, only update-related SEAMCALLs are
> permitted; all other SEAMCALLs must be blocked.
>
> However, SEAMCALLs can be invoked from different contexts (normal and IRQ
> context) and run in parallel across CPUs. And, all TD vCPUs must remain
> out of guest mode during updates.
>
Above it says only update-related SEAMCALLs are permitted. Does that not already
exclude SEAMCALLs that might allow entering the TD?
> No single lock primitive can satisfy
> all these synchronization requirements, so stop_machine() is used as the
> only well-understood mechanism that can meet them all.
>
> The TDX Module update process consists of several steps as described in
> Intel® Trust Domain Extensions (Intel® TDX) Module Base Architecture
> Specification, Revision 348549-007, Chapter 4.5 "TD-Preserving TDX Module
> Update"
>
> - shut down the old module
> - install the new module
> - global and per-CPU initialization
> - restore state information
>
> Some steps must execute on a single CPU, others must run serially across
> all CPUs, and some can run concurrently on all CPUs. There are also
> ordering requirements between steps, so all CPUs must work in a step-locked
> manner.
Does the fact that they can run on other CPUs add any synchronization
requirements? If not I'd leave it off.
>
> In summary, TDX Module updates create two requirements:
The stop_machine() part seems more like a solution then a requirement.
>
> 1. The entire update process must use stop_machine() to synchronize with
> other TDX workloads
> 2. Update steps must be performed in a step-locked manner
>
> To prepare for implementing concrete TDX Module update steps, establish
> the framework by mimicking multi_cpu_stop(), which is a good example of
> performing a multi-step task in step-locked manner.
>
Offline Chao pointed that Paul suggested this after considering refactoring out
the common code. I think it might still be worth mentioning why you can't use
multi_cpu_stop() directly. I guess there are some differences. what are they.
> Specifically, use a
> global state machine to control each CPU's work and require all CPUs to
> acknowledge completion before proceeding to the next step.
Maybe add a bit more about the reasoning for requiring the other steps to ack.
Tie it back to the lockstep part.
>
> Potential alternative to stop_machine()
> =======================================
> An alternative approach is to lock all KVM entry points and kick all
> vCPUs. Here, KVM entry points refer to KVM VM/vCPU ioctl entry points,
> implemented in KVM common code (virt/kvm). Adding a locking mechanism
> there would affect all architectures KVM supports. And to lock only TDX
> vCPUs, new logic would be needed to identify TDX vCPUs, which the KVM
> common code currently lacks. This would add significant complexity and
> maintenance overhead to KVM for this TDX-specific use case.
>
> Signed-off-by: Chao Gao <chao.gao@intel.com>
> Reviewed-by: Xu Yilun <yilun.xu@linux.intel.com>
> Reviewed-by: Tony Lindgren <tony.lindgren@linux.intel.com>
> ---
> v2:
> - refine the changlog to follow context-problem-solution structure
> - move alternative discussions at the end of the changelog
> - add a comment about state machine transition
> - Move rcu_momentary_eqs() call to the else branch.
> ---
> arch/x86/virt/vmx/tdx/seamldr.c | 70 ++++++++++++++++++++++++++++++++-
> 1 file changed, 69 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/virt/vmx/tdx/seamldr.c b/arch/x86/virt/vmx/tdx/seamldr.c
> index 718cb8396057..21d572d75769 100644
> --- a/arch/x86/virt/vmx/tdx/seamldr.c
> +++ b/arch/x86/virt/vmx/tdx/seamldr.c
> @@ -10,8 +10,10 @@
> #include <linux/cpuhplock.h>
> #include <linux/cpumask.h>
> #include <linux/mm.h>
> +#include <linux/nmi.h>
> #include <linux/slab.h>
> #include <linux/spinlock.h>
> +#include <linux/stop_machine.h>
>
> #include <asm/seamldr.h>
>
> @@ -186,6 +188,68 @@ static struct seamldr_params *init_seamldr_params(const u8 *data, u32 size)
> return alloc_seamldr_params(module, module_size, sig, sig_size);
> }
>
> +/*
> + * During a TDX Module update, all CPUs start from TDP_START and progress
> + * to TDP_DONE. Each state is associated with certain work. For some
> + * states, just one CPU needs to perform the work, while other CPUs just
> + * wait during those states.
> + */
> +enum tdp_state {
> + TDP_START,
> + TDP_DONE,
> +};
> +
> +static struct {
> + enum tdp_state state;
> + atomic_t thread_ack;
> +} tdp_data;
> +
> +static void set_target_state(enum tdp_state state)
> +{
> + /* Reset ack counter. */
> + atomic_set(&tdp_data.thread_ack, num_online_cpus());
> + /* Ensure thread_ack is updated before the new state */
> + smp_wmb();
> + WRITE_ONCE(tdp_data.state, state);
> +}
> +
> +/* Last one to ack a state moves to the next state. */
> +static void ack_state(void)
> +{
> + if (atomic_dec_and_test(&tdp_data.thread_ack))
> + set_target_state(tdp_data.state + 1);
> +}
> +
> +/*
> + * See multi_cpu_stop() from where this multi-cpu state-machine was
> + * adopted, and the rationale for touch_nmi_watchdog()
> + */
> +static int do_seamldr_install_module(void *params)
> +{
> + enum tdp_state newstate, curstate = TDP_START;
> + int ret = 0;
> +
> + do {
> + /* Chill out and re-read tdp_data */
> + cpu_relax();
> + newstate = READ_ONCE(tdp_data.state);
> +
> + if (newstate != curstate) {
> + curstate = newstate;
> + switch (curstate) {
Maybe a little comment here like "todo add the steps".
> + default:
> + break;
> + }
> + ack_state();
> + } else {
> + touch_nmi_watchdog();
> + rcu_momentary_eqs();
> + }
> + } while (curstate != TDP_DONE);
> +
> + return ret;
> +}
> +
> DEFINE_FREE(free_seamldr_params, struct seamldr_params *,
> if (!IS_ERR_OR_NULL(_T)) free_seamldr_params(_T))
>
> @@ -223,7 +287,11 @@ int seamldr_install_module(const u8 *data, u32 size)
> return -EBUSY;
> }
>
> - /* TODO: Update TDX Module here */
> + set_target_state(TDP_START + 1);
> + ret = stop_machine_cpuslocked(do_seamldr_install_module, params, cpu_online_mask);
> + if (ret)
> + return ret;
> +
> return 0;
> }
> EXPORT_SYMBOL_FOR_MODULES(seamldr_install_module, "tdx-host");
next prev parent reply other threads:[~2026-03-12 2:00 UTC|newest]
Thread overview: 115+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-12 14:35 [PATCH v4 00/24] Runtime TDX Module update support Chao Gao
2026-02-12 14:35 ` [PATCH v4 01/24] x86/virt/tdx: Move low level SEAMCALL helpers out of <asm/tdx.h> Chao Gao
2026-03-02 12:24 ` Chao Gao
2026-03-05 9:24 ` Binbin Wu
2026-02-12 14:35 ` [PATCH v4 02/24] coco/tdx-host: Introduce a "tdx_host" device Chao Gao
2026-02-20 0:15 ` Huang, Kai
2026-02-24 1:11 ` Chao Gao
2026-03-05 9:25 ` Binbin Wu
2026-03-06 2:13 ` Chao Gao
2026-03-06 4:17 ` Dave Hansen
2026-03-06 5:12 ` Chao Gao
2026-02-12 14:35 ` [PATCH v4 03/24] coco/tdx-host: Expose TDX Module version Chao Gao
2026-02-20 0:40 ` Huang, Kai
2026-02-24 2:02 ` Chao Gao
2026-02-24 10:18 ` Huang, Kai
2026-02-12 14:35 ` [PATCH v4 04/24] x86/virt/seamldr: Introduce a wrapper for P-SEAMLDR SEAMCALLs Chao Gao
2026-02-20 1:12 ` Huang, Kai
2026-02-24 2:31 ` Chao Gao
2026-02-24 10:25 ` Huang, Kai
2026-03-12 20:15 ` Dave Hansen
2026-03-05 9:51 ` Binbin Wu
2026-03-12 20:14 ` Dave Hansen
2026-03-13 8:02 ` Chao Gao
2026-02-12 14:35 ` [PATCH v4 05/24] x86/virt/seamldr: Retrieve P-SEAMLDR information Chao Gao
2026-02-20 9:36 ` Huang, Kai
2026-02-24 2:59 ` Chao Gao
2026-02-24 10:30 ` Huang, Kai
2026-02-12 14:35 ` [PATCH v4 06/24] coco/tdx-host: Expose P-SEAMLDR information via sysfs Chao Gao
2026-03-06 9:29 ` Binbin Wu
2026-02-12 14:35 ` [PATCH v4 07/24] coco/tdx-host: Implement firmware upload sysfs ABI for TDX Module updates Chao Gao
2026-02-27 3:30 ` Xu Yilun
2026-02-27 4:36 ` Xu Yilun
2026-03-10 2:31 ` Yan Zhao
2026-03-12 20:20 ` Dave Hansen
2026-03-13 8:28 ` Chao Gao
2026-02-12 14:35 ` [PATCH v4 08/24] x86/virt/seamldr: Block TDX Module updates if any CPU is offline Chao Gao
2026-03-05 7:02 ` Huang, Kai
2026-03-12 20:20 ` Dave Hansen
2026-03-13 8:17 ` Chao Gao
2026-02-12 14:35 ` [PATCH v4 09/24] x86/virt/seamldr: Check update limit before TDX Module updates Chao Gao
2026-03-05 4:09 ` Xu Yilun
2026-03-05 7:04 ` Huang, Kai
2026-03-12 2:35 ` Yan Zhao
2026-03-12 14:13 ` Chao Gao
2026-03-12 19:21 ` Edgecombe, Rick P
2026-03-12 20:23 ` Dave Hansen
2026-03-13 8:32 ` Chao Gao
2026-02-12 14:35 ` [PATCH v4 10/24] x86/virt/seamldr: Allocate and populate a module update request Chao Gao
2026-02-19 22:31 ` Huang, Kai
2026-02-24 5:15 ` Chao Gao
2026-02-24 10:46 ` Huang, Kai
2026-03-05 4:12 ` Xu Yilun
2026-03-12 2:32 ` Yan Zhao
2026-03-12 14:36 ` Chao Gao
2026-03-12 16:56 ` Edgecombe, Rick P
2026-03-13 12:16 ` Chao Gao
2026-02-12 14:35 ` [PATCH v4 11/24] x86/virt/seamldr: Introduce skeleton for TDX Module updates Chao Gao
2026-02-23 9:25 ` Huang, Kai
2026-02-24 6:00 ` Chao Gao
2026-02-24 10:49 ` Huang, Kai
2026-03-12 2:00 ` Edgecombe, Rick P [this message]
2026-03-12 14:09 ` Chao Gao
2026-03-12 18:05 ` Edgecombe, Rick P
2026-03-13 13:54 ` Chao Gao
2026-03-13 17:43 ` Edgecombe, Rick P
2026-03-12 20:40 ` Dave Hansen
2026-03-13 12:15 ` Chao Gao
2026-02-12 14:35 ` [PATCH v4 12/24] x86/virt/seamldr: Abort updates if errors occurred midway Chao Gao
2026-03-04 22:38 ` Huang, Kai
2026-02-12 14:35 ` [PATCH v4 13/24] x86/virt/seamldr: Shut down the current TDX module Chao Gao
2026-03-04 22:59 ` Huang, Kai
2026-03-06 8:14 ` Chao Gao
2026-03-12 2:34 ` Edgecombe, Rick P
2026-03-05 4:14 ` Xu Yilun
2026-03-12 2:17 ` Edgecombe, Rick P
2026-03-12 2:57 ` Chao Gao
2026-02-12 14:35 ` [PATCH v4 14/24] x86/virt/tdx: Reset software states during TDX Module shutdown Chao Gao
2026-03-04 23:06 ` Huang, Kai
2026-02-12 14:35 ` [PATCH v4 15/24] x86/virt/seamldr: Log TDX Module update failures Chao Gao
2026-03-04 23:08 ` Huang, Kai
2026-03-05 4:18 ` Xu Yilun
2026-02-12 14:35 ` [PATCH v4 16/24] x86/virt/seamldr: Install a new TDX Module Chao Gao
2026-03-04 23:17 ` Huang, Kai
2026-03-05 4:22 ` Xu Yilun
2026-02-12 14:35 ` [PATCH v4 17/24] x86/virt/seamldr: Do TDX per-CPU initialization after updates Chao Gao
2026-03-04 23:18 ` Huang, Kai
2026-02-12 14:35 ` [PATCH v4 18/24] x86/virt/tdx: Restore TDX Module state Chao Gao
2026-03-04 23:24 ` Huang, Kai
2026-02-12 14:35 ` [PATCH v4 19/24] x86/virt/tdx: Update tdx_sysinfo and check features post-update Chao Gao
2026-03-04 23:40 ` Huang, Kai
2026-03-06 8:32 ` Chao Gao
2026-03-06 9:35 ` Huang, Kai
2026-03-12 18:48 ` Edgecombe, Rick P
2026-02-12 14:35 ` [PATCH v4 20/24] x86/virt/tdx: Enable TDX Module runtime updates Chao Gao
2026-02-23 5:09 ` Huang, Kai
2026-02-24 6:02 ` Chao Gao
2026-02-12 14:35 ` [PATCH v4 21/24] x86/virt/tdx: Avoid updates during update-sensitive operations Chao Gao
2026-02-23 4:58 ` Huang, Kai
2026-02-26 3:02 ` Chao Gao
2026-02-26 6:34 ` dan.j.williams
2026-02-26 15:32 ` Chao Gao
2026-02-26 22:06 ` dan.j.williams
2026-02-12 14:35 ` [PATCH v4 22/24] coco/tdx-host: Document TDX Module update expectations Chao Gao
2026-02-12 21:59 ` dan.j.williams
2026-02-12 14:35 ` [PATCH v4 23/24] x86/virt/tdx: Document TDX Module updates Chao Gao
2026-03-04 23:49 ` Huang, Kai
2026-03-12 2:42 ` Edgecombe, Rick P
2026-02-12 14:35 ` [PATCH v4 24/24] [NOT-FOR-REVIEW] x86/virt/seamldr: Save and restore current VMCS Chao Gao
2026-03-11 12:50 ` Chao Gao
2026-03-11 22:06 ` Huang, Kai
2026-03-12 8:48 ` Chao Gao
2026-03-12 9:59 ` Huang, Kai
2026-03-12 15:26 ` Vishal Annapurve
2026-03-12 15:31 ` Dave Hansen
2026-02-12 14:46 ` [PATCH v4 00/24] Runtime TDX Module update support 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=daa8080e1195f586af331dcf31ee5239c4ecbd15.camel@intel.com \
--to=rick.p.edgecombe@intel.com \
--cc=binbin.wu@linux.intel.com \
--cc=bp@alien8.de \
--cc=chao.gao@intel.com \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--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=reinette.chatre@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=yilun.xu@linux.intel.com \
--cc=zhenzhong.duan@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.