Re: [PATCH v4 11/24] x86/virt/seamldr: Introduce skeleton for TDX Module updates

["Edgecombe, Rick P" <rick.p.edgecombe@intel.com>]

On Fri, 2026-03-13 at 21:54 +0800, Chao Gao wrote:
> Or the step details might be irrelevant. Perhaps:
> 
>   TDX module update consists of several steps. Ordering requirements between
>   steps mandate lockstep synchronization across all CPUs.

It seems like enough to understand this patch. Then would you put a little blurb
about the ordering of each step in the later patches?

> 
> > > > > 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.
> > > 
> > > To be clear, Paul didn't actually suggest this approach. His feedback indicated
> > > he wasn't concerned about duplicating some of multi_cpu_stop()'s code, i.e., no
> > > need to refactor out some common code.
> > 
> > Right, sorry for oversimplifying.
> > 
> > > 
> > > https://lore.kernel.org/all/a7affba9-0cea-4493-b868-392158b59d83@paulmck-laptop/#t
> > > 
> > > We can't use multi_cpu_stop() directly because it only provides lockstep
> > > execution for its own infrastructure, not for the function it runs. If we
> > > passed a function that performs steps A, B, and C to multi_cpu_stop(), there's
> > > no guarantee that all CPUs complete step A before any CPU begins step B.
> > 
> > If it could be said more concisely, it seems relevant.
> 
> How about:
> 
> multi_cpu_stop() executes in lockstep but doesn't synchronize steps within the
> callback function it takes. So, implement one based on its pattern.

Yea.