Re: [PATCH v13 20/22] x86/kexec(): Reset TDX private memory on platforms with TDX erratum

[Edgecombe, Rick P]

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?