Re: [PATCH v2 2/5] x86/virt/tdx: Pull kexec cache flush logic into arch/x86

[Chao Gao]

On Mon, Mar 23, 2026 at 02:59:05PM -0600, Vishal Verma wrote:
>From: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx>
>
>KVM tries to take care of some required cache flushing earlier in the
>kexec path in order to be kind to some long standing races that can occur
>later in the operation. Until recently, VMXOFF was handled within KVM.
>Since VMX being enabled is required to make a SEAMCALL, it had the best
>per-cpu scoped operation to plug the flushing into. So it is kicked off
>from there.
>
>This early kexec cache flushing in KVM happens via a syscore shutdown
>callback. Now that VMX enablement control has moved to arch/x86, which has
>grown its own syscore shutdown callback, it no longer make sense for it to
>live in KVM. It fits better with the TDX enablement managing code.
>
>In addition, future changes will add a SEAMCALL that happens immediately
>before VMXOFF, which means the cache flush in KVM will be too late to
>flush the cache before the last SEAMCALL. So move it to the newly added TDX
>arch/x86 syscore shutdown handler.
>
>Since tdx_cpu_flush_cache_for_kexec() is no longer needed by KVM, make it
>static and remove the export. Since it is also not part of an operation
>spread across disparate components, remove the redundant comments and
>verbose naming.
>
>In the existing KVM based code, CPU offline also funnels through
>tdx_cpu_flush_cache_for_kexec(). So the centralization to the arch/x86
>syscore shutdown callback elides this CPU offline time behavior. However,
>WBINVD is already generally done at CPU offline as matter of course. So
>don't bother adding TDX specific logic for this, and rely on the normal
>WBINVD to handle it.
>
>Acked-by: Kai Huang <kai.huang@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>