On Sat, 2023-08-26 at 00:14 +1200, Kai Huang wrote: > diff --git a/arch/x86/kernel/machine_kexec_64.c > b/arch/x86/kernel/machine_kexec_64.c > index 1a3e2c05a8a5..03d9689ef808 100644 > --- a/arch/x86/kernel/machine_kexec_64.c > +++ b/arch/x86/kernel/machine_kexec_64.c > @@ -28,6 +28,7 @@ > #include <asm/setup.h> > #include <asm/set_memory.h> > #include <asm/cpu.h> > +#include <asm/tdx.h> > > #ifdef CONFIG_ACPI > /* > @@ -301,6 +302,14 @@ void machine_kexec(struct kimage *image) > void *control_page; > int save_ftrace_enabled; > > + /* > + * For platforms with TDX "partial write machine check" > erratum, > + * all TDX private pages need to be converted back to normal > + * before booting to the new kernel, otherwise the new kernel > + * may get unexpected machine check. > + */ > + tdx_reset_memory(); > + > #ifdef CONFIG_KEXEC_JUMP > if (image->preserve_context) > save_processor_state(); Without a ton of knowledge on TDX arch stuff, I'm mostly looked at the kexec flow with respect to anything that might be tinkering with the PAMT. Everything there looked good to me. But I'm wondering if you want to skip the tdx_reset_memory() in the KEXEC_JUMP/preserve_context case. Somehow (I'm not clear on all the details), kexec can be configured to have the new kernel jump back to the old kernel and resume execution as if nothing happened. Then I think you would want to keep the TDX data around. Does that make any sense?
