From: Dave Hansen <dave.hansen@linux.intel.com>
To: dave.hansen@linux.intel.com
Subject: Re: [PATCH v9 15/23] x86/virt/tdx: Reset software states during TDX module shutdown
In-Reply-To: <20260513151045.1420990-16-chao.gao@intel.com>
References: <20260513151045.1420990-16-chao.gao@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

[Draft review generated by x86-maintainer-agent applying Dave_Hansen.txt
 rules to the v9 series.  Strip this banner before sending.]

Functionally this and 14/23 are one logical change ("the SHUTDOWN step
of the update").  If you'd rather keep them split, that's fine, but
the changelogs should cross-reference each other so a reader of 14/23
alone doesn't conclude the shutdown is missing the cleanup.

> +	/*
> +	 * Clear global and per-CPU initialization flags so the new module
> +	 * can be fully re-initialized after a successful update.
> +	 *
> +	 * No locks needed as no concurrent accesses can occur here.
> +	 */
> +	memset(&tdx_module_state, 0, sizeof(tdx_module_state));
> +	for_each_possible_cpu(cpu)
> +		per_cpu(tdx_lp_initialized, cpu) = false;

The "no locks needed" comment is the right thing (RULE 2) -- it's
exactly the question a reviewer asks when they see a memset over
shared state.  Calling out that this runs under stop_machine() would
seal the deal:

  /*
   * Called from the SHUTDOWN step of a stop_machine() flow; all other
   * CPUs are in the same flow waiting on the state machine, so no
   * concurrent readers are possible.
   */

Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com>  [with the
                                                        stop_machine
                                                        note]