[PATCH v3 4/6] x86/virt/tdx: Remove the !KEXEC_CORE dependency

Kai Huang posted 6 patches 3 months, 2 weeks ago
There is a newer version of this series
[PATCH v3 4/6] x86/virt/tdx: Remove the !KEXEC_CORE dependency
Posted by Kai Huang 3 months, 2 weeks ago
During kexec it is now guaranteed that all dirty cachelines of TDX
private memory are flushed before jumping to the new kernel.  The TDX
private memory from the old kernel will remain as TDX private memory in
the new kernel, but it is OK because kernel read/write to TDX private
memory will never cause machine check, except on the platforms with the
TDX partial write erratum, which has already been handled.

It is safe to allow kexec to work together with TDX now.  Remove the
!KEXEC_CORE dependency.

Signed-off-by: Kai Huang <kai.huang@intel.com>
Tested-by: Farrah Chen <farrah.chen@intel.com>
---
 arch/x86/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 71019b3b54ea..ca1c9f9e59be 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1899,7 +1899,6 @@ config INTEL_TDX_HOST
 	depends on X86_X2APIC
 	select ARCH_KEEP_MEMBLOCK
 	depends on CONTIG_ALLOC
-	depends on !KEXEC_CORE
 	depends on X86_MCE
 	help
 	  Intel Trust Domain Extensions (TDX) protects guest VMs from malicious
-- 
2.49.0
Re: [PATCH v3 4/6] x86/virt/tdx: Remove the !KEXEC_CORE dependency
Posted by Edgecombe, Rick P 3 months, 1 week ago
On Thu, 2025-06-26 at 22:48 +1200, Kai Huang wrote:
> During kexec it is now guaranteed that all dirty cachelines of TDX
> private memory are flushed before jumping to the new kernel.  The TDX
> private memory from the old kernel will remain as TDX private memory in
> the new kernel, but it is OK because kernel read/write to TDX private
> memory will never cause machine check, except on the platforms with the
> TDX partial write erratum, which has already been handled.
> 
> It is safe to allow kexec to work together with TDX now.  Remove the
> !KEXEC_CORE dependency.
> 
> Signed-off-by: Kai Huang <kai.huang@intel.com>
> Tested-by: Farrah Chen <farrah.chen@intel.com>

Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com>