Re: [PATCH 4/7] x86/kexec: Disable kexec/kdump on platforms with TDX partial write erratum

["Huang, Kai" <kai.huang@intel.com>]

On Tue, 2025-10-21 at 19:50 -0700, Vishal Annapurve wrote:
> On Tue, Oct 21, 2025 at 10:08 AM Dave Hansen <dave.hansen@intel.com> wrote:
> > 
> > On 10/18/25 08:54, Vishal Annapurve wrote:
> > > Circling bank on this topic, I would like to iterate a few points:
> > > 1) Google has been running workloads with the series [1] for ~2 years
> > > now, we haven't seen any issues with kdump functionality across kernel
> > > bugs, real hardware issues, private memory corruption etc.
> > 
> > Great points and great info!
> > 
> > As a next step, I'd expect someone (at Google) to take this into
> > consideration and put together a series to have the kernel comprehend
> > those points.
> 
> Then is it safe to say that Intel doesn't consider:
> * Adding the support to just reset PAMT memory [1] to this series and

You need to reset all TDX private memory including TDX guest private
memory, S-EPT pages etc, and PAMT.  Resetting PAMT alone won't be enough,
and is pointless.

When [1] was posted, KVM TDX hadn't landed yet, so the only type of TDX
private memory was PAMT, but there's also a big comment there to point out
the in-kernel users should be responsible for resetting any TDX private
memory that they manage:

+	/*
+	 * It's ideal to cover all types of TDX private pages here, but
+	 * currently there's no unified way to tell whether a given page
+	 * is TDX private page or not.
+	 *
+	 * Only convert PAMT here.  All in-kernel TDX users (e.g., KVM)
+	 * are responsible for converting TDX private pages that are
+	 * managed by them by either registering reboot notifier or
+	 * shutdown syscore ops.
+	 */
+	tdmrs_reset_pamt_all(&tdx_tdmr_list);

> * Modifying the logic in this patch [2] to enable kdump and keep kexec
> support disabled in this series

Resetting TDX private is a complete solution which allows to enable both
kdump and kexec.  If we choose to reset TDX private memory, then we can
just revert [2].

> 
> as a viable direction upstream for now until a better solution comes along?

The alternative could be to simply modify [2] to allow kdump (but leave
TDX private memory untouched to the new kernel) but not normal kexec.  The
risk of doing so has already been covered in this thread AFAICT:

 1) If the kdump kernel does partial write to vmcore, the kdump kernel may
    see unexpected #MCE.
 2) As Elena pointed out, if the old kernel has bug and somehow already
    does partial write to TDX private memory (which leads to poison), the
    consumption of such poison may be deferred to the kdump kernel.

> 
> If not, can kdump be made optional as Juergen suggested?

IIUC Juergen suggested:

  Then we could add a kernel boot parameter to let the user opt-in
  for kexec being possible in spite of the potential #MC.

I don't have opinion on this, other than that I think the boot parameter
only makes sense if we do the "alternative" mentioned above, i.e., not
resetting TDX private memory.

> 
> [1] https://lore.kernel.org/lkml/6960ef6d7ee9398d164bf3997e6009df3e88cb67.1727179214.git.kai.huang@intel.com/
> [2] https://lore.kernel.org/all/20250901160930.1785244-5-pbonzini@redhat.com/