Re: [PATCH v2 3/5] x86/virt/tdx: Add SEAMCALL wrapper for TDH.SYS.DISABLE

[Chao Gao]

On Mon, Mar 23, 2026 at 02:59:06PM -0600, Vishal Verma wrote:
>Some early TDX-capable platforms have an erratum where a partial write
>to TDX private memory can cause a machine check on a subsequent read.
>On these platforms, kexec and kdump have been disabled in these cases,
>because the old kernel cannot safely hand off TDX state to the new
>kernel. Later TDX modules support the TDH.SYS.DISABLE SEAMCALL, which
>provides a way to cleanly disable TDX and allow kexec to proceed.
>
>The new SEAMCALL has an enumeration bit, but that is ignored. It is
>expected that users will be using the latest TDX module, and the failure
>mode for running the missing SEAMCALL on an older module is not fatal.
>
>This can be a long running operation, and the time needed largely
>depends on the amount of memory that has been allocated to TDs. If all
>TDs have been destroyed prior to the sys_disable call, then it is fast,
>with only needing to override the TDX module memory.
>
>After the SEAMCALL completes, the TDX module is disabled and all memory
>resources allocated to TDX are freed and reset. The next kernel can then
>re-initialize the TDX module from scratch via the normal TDX bring-up
>sequence.
>
>The SEAMCALL can return two different error codes that expect a retry.
> - TDX_INTERRUPTED_RESUMABLE can be returned in the case of a host
>   interrupt. However, it will not return until it makes some forward
>   progress, so we can expect to complete even in the case of interrupt
>   storms.
> - TDX_SYS_BUSY will be returned on contention with other TDH.SYS.*
>   SEAMCALLs, however a side effect of TDH.SYS.DISABLE is that it will
>   block other SEAMCALLs once it gets going. So this contention will be
>   short lived.
>
>So loop infinitely on either of these error codes, until success or other
>error.
>
>Co-developed-by: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx>
>Signed-off-by: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx>
>Signed-off-by: Vishal Verma <vishal.l.verma@xxxxxxxxx>

Reviewed-by: Chao Gao <chao.gao@xxxxxxxxx>