Re: [PATCH v6 12/22] x86/virt/tdx: Reset software states during TDX module shutdown

[Chao Gao <chao.gao@intel.com>]

> int tdx_module_shutdown(void)
> {
> 	struct tdx_module_args args = {};
>+	int ret, cpu;
> 
> 	/*
> 	 * Shut down the TDX module and prepare handoff data for the next
>@@ -1188,7 +1189,23 @@ int tdx_module_shutdown(void)
> 	 * modules as new modules likely have higher handoff version.
> 	 */
> 	args.rcx = tdx_sysinfo.handoff.module_hv;
>-	return seamcall_prerr(TDH_SYS_SHUTDOWN, &args);
>+	ret = seamcall_prerr(TDH_SYS_SHUTDOWN, &args);
>+	if (ret)
>+		return ret;
>+
>+	tdx_module_status = TDX_MODULE_UNINITIALIZED;

Sashiko commented:
"""
If a TDX module update fails after this shutdown completes, does this leave
the system in an unrecoverable state?
Since tdx_module_status is left as TDX_MODULE_UNINITIALIZED, if KVM is
later reloaded, it appears it will call tdx_enable(), observe the
uninitialized status, and invoke init_tdx_module() again.
Because init_tdx_module() is not re-entrant, won't it blindly append
duplicate memory regions to the global tdx_memlist and allocate new TDMR
arrays and PAMT memory?
This seems like it would permanently leak the previous allocations and
eventually fail when construct_tdmrs() rejects overlapping TDMRs. Is there
a mechanism to prevent re-initialization if the subsequent update steps fail?
"""

This is a valid issue.

A fix is: set tdx_module_status to TDX_MODULE_ERROR here. Failures preserve
ERROR state; success explicitly transitions to INITIALIZED (patch 15).
Alternatively, we could introduce a dedicated shutdown state.

Note that the VMXON series moves TDX initialization to boot time, eliminating
runtime re-initialization (init_tdx_module() calls) entirely.