Re: [PATCH v12 19/22] x86/kexec(): Reset TDX private memory on platforms with TDX erratum

From: Huang, Kai
Date: Wed Jun 28 2023 - 20:28:03 EST


On Wed, 2023-06-28 at 15:29 +0300, kirill.shutemov@xxxxxxxxxxxxxxx wrote:
> On Tue, Jun 27, 2023 at 02:12:49AM +1200, Kai Huang wrote:
> > @@ -1113,6 +1115,17 @@ static int init_tdx_module(void)
> > */
> > wbinvd_on_all_cpus();
> >
> > + /*
> > + * Starting from this point the system may have TDX private
> > + * memory. Make it globally visible so tdx_reset_memory() only
> > + * reads TDMRs/PAMTs when they are stable.
> > + *
> > + * Note using atomic_inc_return() to provide the explicit memory
> > + * ordering isn't mandatory here as the WBINVD above already
> > + * does that. Compiler barrier isn't needed here either.
> > + */
> > + atomic_inc_return(&tdx_may_has_private_mem);
>
> Why do we need atomics at all here? Writers seems serialized with
> tdx_module_lock and reader accesses the variable when all CPUs, but one is
> down and cannot race.
>

In kexec() the reader reads this when all remote cpus are dead w/o holding
module lock. All remote cpus can be stopped at _ANY_ time, meaning they can be
stopped right in any place in middle of init_tdx_module(). IIUC the module lock
doesn't help here.