From: Kai Huang <kai.huang@intel.com>

Some early TDX-capable platforms have an erratum: A kernel partial
write (a write transaction of less than cacheline lands at memory
controller) to TDX private memory poisons that memory, and a subsequent
read triggers a machine check.

On those platforms, the old kernel must reset TDX private memory before
jumping to the new kernel, otherwise the new kernel may see unexpected
machine check.  Currently the kernel doesn't track which page is a TDX
private page.  For simplicity just fail kexec/kdump for those platforms.

Leverage the existing machine_kexec_prepare() to fail kexec/kdump by
adding the check of the presence of the TDX erratum (which is only
checked for if the kernel is built with TDX host support).  This rejects
kexec/kdump when the kernel is loading the kexec/kdump kernel image.

The alternative is to reject kexec/kdump when the kernel is jumping to
the new kernel.  But for kexec this requires adding a new check (e.g.,
arch_kexec_allowed()) in the common code to fail kernel_kexec() at early
stage.  Kdump (crash_kexec()) needs similar check, but it's hard to
justify because crash_kexec() is not supposed to abort.

It's feasible to further relax this limitation, i.e., only fail kexec
when TDX is actually enabled by the kernel.  But this is still a half
measure compared to resetting TDX private memory so just do the simplest
thing for now.

The impact to userspace is the users will get an error when loading the
kexec/kdump kernel image:

  kexec_load failed: Operation not supported

This might be confusing to the users, thus also print the reason in the
dmesg:

  [..] kexec: Not allowed on platform with tdx_pw_mce bug.

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>
Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 arch/x86/kernel/machine_kexec_64.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c
index 34c303a92eaf..201137b98fb8 100644
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -347,6 +347,22 @@ int machine_kexec_prepare(struct kimage *image)
 	unsigned long reloc_end = (unsigned long)__relocate_kernel_end;
 	int result;
 
+	/*
+	 * Some early TDX-capable platforms have an erratum.  A kernel
+	 * partial write (a write transaction of less than cacheline
+	 * lands at memory controller) to TDX private memory poisons that
+	 * memory, and a subsequent read triggers a machine check.
+	 *
+	 * On those platforms the old kernel must reset TDX private
+	 * memory before jumping to the new kernel otherwise the new
+	 * kernel may see unexpected machine check.  For simplicity
+	 * just fail kexec/kdump on those platforms.
+	 */
+	if (boot_cpu_has_bug(X86_BUG_TDX_PW_MCE)) {
+		pr_info_once("Not allowed on platform with tdx_pw_mce bug\n");
+		return -EOPNOTSUPP;
+	}
+
 	/* Setup the identity mapped 64bit page table */
 	result = init_pgtable(image, __pa(control_page));
 	if (result)
-- 
2.51.0

On Mon, Sep 1, 2025 at 9:11 AM Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> From: Kai Huang <kai.huang@intel.com>
>
> Some early TDX-capable platforms have an erratum: A kernel partial
> write (a write transaction of less than cacheline lands at memory
> controller) to TDX private memory poisons that memory, and a subsequent
> read triggers a machine check.
>
> On those platforms, the old kernel must reset TDX private memory before
> jumping to the new kernel, otherwise the new kernel may see unexpected
> machine check.  Currently the kernel doesn't track which page is a TDX
> private page.  For simplicity just fail kexec/kdump for those platforms.

Google has a usecase that needs host kdump support on SPR/EMR
platforms. Disabling kdump disables the host's ability to dump very
critical information on host crashes altogether. Is Intel working on
enabling kdump support for platforms with the erratum?

On 9/29/25 18:38, Vishal Annapurve wrote:
>> On those platforms, the old kernel must reset TDX private memory before
>> jumping to the new kernel, otherwise the new kernel may see unexpected
>> machine check.  Currently the kernel doesn't track which page is a TDX
>> private page.  For simplicity just fail kexec/kdump for those platforms.
> Google has a usecase that needs host kdump support on SPR/EMR
> platforms. Disabling kdump disables the host's ability to dump very
> critical information on host crashes altogether. Is Intel working on
> enabling kdump support for platforms with the erratum?

Nope.

Any workarounds are going to be slow and probably imperfect. That's not
a great match for kdump. I'm perfectly happy waiting for fixed hardware
from what I've seen.

On Tue, Sep 30, 2025 at 2:32 PM Dave Hansen <dave.hansen@intel.com> wrote:
>
> On 9/29/25 18:38, Vishal Annapurve wrote:
> >> On those platforms, the old kernel must reset TDX private memory before
> >> jumping to the new kernel, otherwise the new kernel may see unexpected
> >> machine check.  Currently the kernel doesn't track which page is a TDX
> >> private page.  For simplicity just fail kexec/kdump for those platforms.
> > Google has a usecase that needs host kdump support on SPR/EMR
> > platforms. Disabling kdump disables the host's ability to dump very
> > critical information on host crashes altogether. Is Intel working on
> > enabling kdump support for platforms with the erratum?
>
> Nope.
>
> Any workarounds are going to be slow and probably imperfect. That's not

Do we really need to deploy workarounds that are complex and slow to
get kdump working for the majority of the scenarios? Is there any
analysis done for the risk with imperfect and simpler workarounds vs
benefits of kdump functionality?

> a great match for kdump. I'm perfectly happy waiting for fixed hardware
> from what I've seen.

IIUC SPR/EMR - two CPU generations out there are impacted by this
erratum and just disabling kdump functionality IMO is not the best
solution here.

On 9/30/25 19:05, Vishal Annapurve wrote:
...
>> Any workarounds are going to be slow and probably imperfect. That's not
> 
> Do we really need to deploy workarounds that are complex and slow to
> get kdump working for the majority of the scenarios? Is there any
> analysis done for the risk with imperfect and simpler workarounds vs
> benefits of kdump functionality?
> 
>> a great match for kdump. I'm perfectly happy waiting for fixed hardware
>> from what I've seen.
> 
> IIUC SPR/EMR - two CPU generations out there are impacted by this
> erratum and just disabling kdump functionality IMO is not the best
> solution here.

That's an eminently reasonable position. But we're speaking in broad
generalities and I'm unsure what you don't like about the status quo or
how you'd like to see things change.

Care to send along a patch representing the "best solution"? That should
clear things up.

On Wed, Oct 1, 2025 at 7:32 AM Dave Hansen <dave.hansen@intel.com> wrote:
>
> On 9/30/25 19:05, Vishal Annapurve wrote:
> ...
> >> Any workarounds are going to be slow and probably imperfect. That's not
> >
> > Do we really need to deploy workarounds that are complex and slow to
> > get kdump working for the majority of the scenarios? Is there any
> > analysis done for the risk with imperfect and simpler workarounds vs
> > benefits of kdump functionality?
> >
> >> a great match for kdump. I'm perfectly happy waiting for fixed hardware
> >> from what I've seen.
> >
> > IIUC SPR/EMR - two CPU generations out there are impacted by this
> > erratum and just disabling kdump functionality IMO is not the best
> > solution here.
>
> That's an eminently reasonable position. But we're speaking in broad
> generalities and I'm unsure what you don't like about the status quo or
> how you'd like to see things change.

Looks like the decision to disable kdump was taken between [1] -> [2].
"The kernel currently doesn't track which page is TDX private memory.
It's not trivial to reset TDX private memory.  For simplicity, this
series simply disables kexec/kdump for such platforms.  This will be
enhanced in the future."

A patch [3] from the series[1], describes the issue as:
"This problem is triggered by "partial" writes where a write transaction
of less than cacheline lands at the memory controller.  The CPU does
these via non-temporal write instructions (like MOVNTI), or through
UC/WC memory mappings.  The issue can also be triggered away from the
CPU by devices doing partial writes via DMA."

And also mentions:
"Also note only the normal kexec needs to worry about this problem, but
not the crash kexec: 1) The kdump kernel only uses the special memory
reserved by the first kernel, and the reserved memory can never be used
by TDX in the first kernel; 2) The /proc/vmcore, which reflects the
first (crashed) kernel's memory, is only for read.  The read will never
"poison" TDX memory thus cause unexpected machine check (only partial
write does)."

What was the scenario that led to disabling kdump support altogether
given the above description?

[1] https://lore.kernel.org/lkml/cover.1727179214.git.kai.huang@intel.com/
[2] https://lore.kernel.org/all/cover.1741778537.git.kai.huang@intel.com/
[3] https://lore.kernel.org/lkml/6960ef6d7ee9398d164bf3997e6009df3e88cb67.1727179214.git.kai.huang@intel.com/

>
> Care to send along a patch representing the "best solution"? That should
> clear things up.
>

> On Wed, Oct 1, 2025 at 7:32 AM Dave Hansen <dave.hansen@intel.com>
> wrote:
> >
> > On 9/30/25 19:05, Vishal Annapurve wrote:
> > ...
> > >> Any workarounds are going to be slow and probably imperfect. That's not
> > >
> > > Do we really need to deploy workarounds that are complex and slow to
> > > get kdump working for the majority of the scenarios? Is there any
> > > analysis done for the risk with imperfect and simpler workarounds vs
> > > benefits of kdump functionality?
> > >
> > >> a great match for kdump. I'm perfectly happy waiting for fixed hardware
> > >> from what I've seen.
> > >
> > > IIUC SPR/EMR - two CPU generations out there are impacted by this
> > > erratum and just disabling kdump functionality IMO is not the best
> > > solution here.
> >
> > That's an eminently reasonable position. But we're speaking in broad
> > generalities and I'm unsure what you don't like about the status quo or
> > how you'd like to see things change.
> 
> Looks like the decision to disable kdump was taken between [1] -> [2].
> "The kernel currently doesn't track which page is TDX private memory.
> It's not trivial to reset TDX private memory.  For simplicity, this
> series simply disables kexec/kdump for such platforms.  This will be
> enhanced in the future."
> 
> A patch [3] from the series[1], describes the issue as:
> "This problem is triggered by "partial" writes where a write transaction
> of less than cacheline lands at the memory controller.  The CPU does
> these via non-temporal write instructions (like MOVNTI), or through
> UC/WC memory mappings.  The issue can also be triggered away from the
> CPU by devices doing partial writes via DMA."
> 
> And also mentions:
> "Also note only the normal kexec needs to worry about this problem, but
> not the crash kexec: 1) The kdump kernel only uses the special memory
> reserved by the first kernel, and the reserved memory can never be used
> by TDX in the first kernel; 2) The /proc/vmcore, which reflects the
> first (crashed) kernel's memory, is only for read.  The read will never
> "poison" TDX memory thus cause unexpected machine check (only partial
> write does)."

While the statement that the read will never poison the memory is correct,
the situation we can theoretically worry about is the following in my understanding:

1. During its execution on platform with partial write problem, host OS or other
actor executing outside of SEAM mode triggers partial write into a cache line that
originally belonged to TDX private memory. 
This is smth that host OS or other entities should not do, but it could happen due
to host OS bugs, etc. 
2. The above causes the specified cache line to be poisoned by mem controller. 
However, here we assume that no one accesses this cache line from TDX module,
TD guests or Host OS for the time being and the problem remains hidden.
3. Host OS crashes due to some other issue, kdump crash kernel is triggered,
and kdump starts to read all the memory from the previous host kernel to dump
the diagnostics info.
4. At some point of time, kdump crash kernel reaches the memory with the poisoned
cache line, consumes poison, and the #MC is issued for the kernel space. 

Isn't this the reason for also disabling kdump? Or do I miss smth?

Best Regards,
Elena.

On 02.10.25 08:59, Reshetova, Elena wrote:
>> On Wed, Oct 1, 2025 at 7:32 AM Dave Hansen <dave.hansen@intel.com>
>> wrote:
>>>
>>> On 9/30/25 19:05, Vishal Annapurve wrote:
>>> ...
>>>>> Any workarounds are going to be slow and probably imperfect. That's not
>>>>
>>>> Do we really need to deploy workarounds that are complex and slow to
>>>> get kdump working for the majority of the scenarios? Is there any
>>>> analysis done for the risk with imperfect and simpler workarounds vs
>>>> benefits of kdump functionality?
>>>>
>>>>> a great match for kdump. I'm perfectly happy waiting for fixed hardware
>>>>> from what I've seen.
>>>>
>>>> IIUC SPR/EMR - two CPU generations out there are impacted by this
>>>> erratum and just disabling kdump functionality IMO is not the best
>>>> solution here.
>>>
>>> That's an eminently reasonable position. But we're speaking in broad
>>> generalities and I'm unsure what you don't like about the status quo or
>>> how you'd like to see things change.
>>
>> Looks like the decision to disable kdump was taken between [1] -> [2].
>> "The kernel currently doesn't track which page is TDX private memory.
>> It's not trivial to reset TDX private memory.  For simplicity, this
>> series simply disables kexec/kdump for such platforms.  This will be
>> enhanced in the future."
>>
>> A patch [3] from the series[1], describes the issue as:
>> "This problem is triggered by "partial" writes where a write transaction
>> of less than cacheline lands at the memory controller.  The CPU does
>> these via non-temporal write instructions (like MOVNTI), or through
>> UC/WC memory mappings.  The issue can also be triggered away from the
>> CPU by devices doing partial writes via DMA."
>>
>> And also mentions:
>> "Also note only the normal kexec needs to worry about this problem, but
>> not the crash kexec: 1) The kdump kernel only uses the special memory
>> reserved by the first kernel, and the reserved memory can never be used
>> by TDX in the first kernel; 2) The /proc/vmcore, which reflects the
>> first (crashed) kernel's memory, is only for read.  The read will never
>> "poison" TDX memory thus cause unexpected machine check (only partial
>> write does)."
> 
> While the statement that the read will never poison the memory is correct,
> the situation we can theoretically worry about is the following in my understanding:
> 
> 1. During its execution on platform with partial write problem, host OS or other
> actor executing outside of SEAM mode triggers partial write into a cache line that
> originally belonged to TDX private memory.
> This is smth that host OS or other entities should not do, but it could happen due
> to host OS bugs, etc.
> 2. The above causes the specified cache line to be poisoned by mem controller.
> However, here we assume that no one accesses this cache line from TDX module,
> TD guests or Host OS for the time being and the problem remains hidden.
> 3. Host OS crashes due to some other issue, kdump crash kernel is triggered,
> and kdump starts to read all the memory from the previous host kernel to dump
> the diagnostics info.
> 4. At some point of time, kdump crash kernel reaches the memory with the poisoned
> cache line, consumes poison, and the #MC is issued for the kernel space.
> 
> Isn't this the reason for also disabling kdump? Or do I miss smth?

So lets compare the 2 cases with kdump enabled and disabled in your scenario
(crash of the host OS):

kdump enabled: No dump can be produced due to the #MC and system is rebooted.

kdump disabled: No dump is produced and system is rebooted after crash.

What is the main concern with kdump enabled? I don't see any disadvantage with
enabling it, just the advantage that in many cases a dump will be written.


Juergen

On 10/2/25 00:46, Juergen Gross wrote:
> So lets compare the 2 cases with kdump enabled and disabled in your 
> scenario (crash of the host OS):
> 
> kdump enabled: No dump can be produced due to the #MC and system is
> rebooted.
> 
> kdump disabled: No dump is produced and system is rebooted after crash.
> > What is the main concern with kdump enabled? I don't see any
> disadvantage with enabling it, just the advantage that in many cases
> a dump will be written.
The disadvantage is that a kernel bug from long ago results in a machine
check. Machine checks are generally indicative of bad hardware. So the
disadvantage is that someone mistakes the long ago kernel bug for bad
hardware.

There are two ways of looking at this:

1. A theoretically fragile kdump is better than no kdump at all. All of
   the stars would have to align for kdump to _fail_ and we don't think
   that's going to happen often enough to matter.
2. kdump happens after kernel bugs. The machine checks happen because of
   kernel bugs. It's not a big stretch to think that, at scale, kdump is
   going to run in to these #MCs on a regular basis.

Does that capture the two perspectives fairly?

On Thu, Oct 2, 2025 at 8:06 AM Dave Hansen <dave.hansen@intel.com> wrote:
>
> On 10/2/25 00:46, Juergen Gross wrote:
> > So lets compare the 2 cases with kdump enabled and disabled in your
> > scenario (crash of the host OS):
> >
> > kdump enabled: No dump can be produced due to the #MC and system is
> > rebooted.
> >
> > kdump disabled: No dump is produced and system is rebooted after crash.
> > > What is the main concern with kdump enabled? I don't see any
> > disadvantage with enabling it, just the advantage that in many cases
> > a dump will be written.
> The disadvantage is that a kernel bug from long ago results in a machine
> check. Machine checks are generally indicative of bad hardware. So the
> disadvantage is that someone mistakes the long ago kernel bug for bad
> hardware.
>
> There are two ways of looking at this:
>
> 1. A theoretically fragile kdump is better than no kdump at all. All of
>    the stars would have to align for kdump to _fail_ and we don't think
>    that's going to happen often enough to matter.
> 2. kdump happens after kernel bugs. The machine checks happen because of
>    kernel bugs. It's not a big stretch to think that, at scale, kdump is
>    going to run in to these #MCs on a regular basis.

Looking at Elena's response, I would say it's still *a* big stretch
for kdump to run into these #MCs on a regular basis as following
sequence is needed for problematic scenario:
1) Host OS bug should corrupt TDX private memory with a *partial
write*, that is part of kernel memory.
    -> i.e. PAMT tables, SEPT tables, TD VCPU/VM metadata etc.
    -> IIUC corruption of guest memory is not a concern as that
belongs to userspace.
2) TDX Module/TD shouldn't consume that poisoned memory.
    -> i.e. no walk of the metadata memory.
3) Host kernel needs to generate a bug that causes an orthogonal panic.

*partial writes* IIUC need special instructions.

>
> Does that capture the two perspectives fairly?

> On 02.10.25 08:59, Reshetova, Elena wrote:
> >> On Wed, Oct 1, 2025 at 7:32 AM Dave Hansen <dave.hansen@intel.com>
> >> wrote:
> >>>
> >>> On 9/30/25 19:05, Vishal Annapurve wrote:
> >>> ...
> >>>>> Any workarounds are going to be slow and probably imperfect. That's
> not
> >>>>
> >>>> Do we really need to deploy workarounds that are complex and slow to
> >>>> get kdump working for the majority of the scenarios? Is there any
> >>>> analysis done for the risk with imperfect and simpler workarounds vs
> >>>> benefits of kdump functionality?
> >>>>
> >>>>> a great match for kdump. I'm perfectly happy waiting for fixed hardware
> >>>>> from what I've seen.
> >>>>
> >>>> IIUC SPR/EMR - two CPU generations out there are impacted by this
> >>>> erratum and just disabling kdump functionality IMO is not the best
> >>>> solution here.
> >>>
> >>> That's an eminently reasonable position. But we're speaking in broad
> >>> generalities and I'm unsure what you don't like about the status quo or
> >>> how you'd like to see things change.
> >>
> >> Looks like the decision to disable kdump was taken between [1] -> [2].
> >> "The kernel currently doesn't track which page is TDX private memory.
> >> It's not trivial to reset TDX private memory.  For simplicity, this
> >> series simply disables kexec/kdump for such platforms.  This will be
> >> enhanced in the future."
> >>
> >> A patch [3] from the series[1], describes the issue as:
> >> "This problem is triggered by "partial" writes where a write transaction
> >> of less than cacheline lands at the memory controller.  The CPU does
> >> these via non-temporal write instructions (like MOVNTI), or through
> >> UC/WC memory mappings.  The issue can also be triggered away from the
> >> CPU by devices doing partial writes via DMA."
> >>
> >> And also mentions:
> >> "Also note only the normal kexec needs to worry about this problem, but
> >> not the crash kexec: 1) The kdump kernel only uses the special memory
> >> reserved by the first kernel, and the reserved memory can never be used
> >> by TDX in the first kernel; 2) The /proc/vmcore, which reflects the
> >> first (crashed) kernel's memory, is only for read.  The read will never
> >> "poison" TDX memory thus cause unexpected machine check (only partial
> >> write does)."
> >
> > While the statement that the read will never poison the memory is correct,
> > the situation we can theoretically worry about is the following in my
> understanding:
> >
> > 1. During its execution on platform with partial write problem, host OS or
> other
> > actor executing outside of SEAM mode triggers partial write into a cache line
> that
> > originally belonged to TDX private memory.
> > This is smth that host OS or other entities should not do, but it could happen
> due
> > to host OS bugs, etc.
> > 2. The above causes the specified cache line to be poisoned by mem
> controller.
> > However, here we assume that no one accesses this cache line from TDX
> module,
> > TD guests or Host OS for the time being and the problem remains hidden.
> > 3. Host OS crashes due to some other issue, kdump crash kernel is triggered,
> > and kdump starts to read all the memory from the previous host kernel to
> dump
> > the diagnostics info.
> > 4. At some point of time, kdump crash kernel reaches the memory with the
> poisoned
> > cache line, consumes poison, and the #MC is issued for the kernel space.
> >
> > Isn't this the reason for also disabling kdump? Or do I miss smth?
> 
> So lets compare the 2 cases with kdump enabled and disabled in your scenario
> (crash of the host OS):
> 
> kdump enabled: No dump can be produced due to the #MC and system is
> rebooted.
> 
> kdump disabled: No dump is produced and system is rebooted after crash.
> 
> What is the main concern with kdump enabled? I don't see any disadvantage
> with
> enabling it, just the advantage that in many cases a dump will be written.

I am not in the position to judge about what should be done about kdump in Linux,
neither I am arguing one way or another.
I just wanted to fill the gap and explain the technical scenario above
which I think was missing from this thread. Whatever decision is taken by 
community should rely on understanding the HW behaviour, so this is what
I tried to explain above.

Best Regards,
Elena.

On 10/1/25 10:17, Vishal Annapurve wrote:
> And also mentions:
> "Also note only the normal kexec needs to worry about this problem, but
> not the crash kexec: 1) The kdump kernel only uses the special memory
> reserved by the first kernel, and the reserved memory can never be used
> by TDX in the first kernel; 2) The /proc/vmcore, which reflects the
> first (crashed) kernel's memory, is only for read.  The read will never
> "poison" TDX memory thus cause unexpected machine check (only partial
> write does)."
> 
> What was the scenario that led to disabling kdump support altogether
> given the above description?

I think it was purely out of convenience so that the disabling could be
three lines of code.

I don't know off the top of my head if there's a simple enough way to
disable kexec but not kdump. When I applied the thing, I was probably
just considering kexec/kdump a monolithic thing and not thinking that
folks would want one but not the other.

Kai, did you have any other motivations?

On Wed, 2025-10-01 at 11:00 -0700, Hansen, Dave wrote:
> On 10/1/25 10:17, Vishal Annapurve wrote:
> > And also mentions:
> > "Also note only the normal kexec needs to worry about this problem, but
> > not the crash kexec: 1) The kdump kernel only uses the special memory
> > reserved by the first kernel, and the reserved memory can never be used
> > by TDX in the first kernel; 2) The /proc/vmcore, which reflects the
> > first (crashed) kernel's memory, is only for read.  The read will never
> > "poison" TDX memory thus cause unexpected machine check (only partial
> > write does)."
> > 
> > What was the scenario that led to disabling kdump support altogether
> > given the above description?
> 
> I think it was purely out of convenience so that the disabling could be
> three lines of code.
> 
> I don't know off the top of my head if there's a simple enough way to
> disable kexec but not kdump. When I applied the thing, I was probably
> just considering kexec/kdump a monolithic thing and not thinking that
> folks would want one but not the other.
> 
> Kai, did you have any other motivations?

The "/proc/vmcore is only for read" is my understanding of how the kdump
kernel uses the /proc/vmcore.  I used to only disable kexec but allow
kdump to work (something like the diff below [*]), but during the internal
review we decided to just disable all since we cannot be sure whether it
is 100% true for all the kdump users.

This was raised by Vishal publicly before and was discussed here (in v3):

https://lore.kernel.org/kvm/f8dcbe257b3931aec9e199132b678bd7681b7efa.camel@intel.com/

[*]:

diff --git a/arch/x86/kernel/machine_kexec_64.c
b/arch/x86/kernel/machine_kexec_64.c
index 15088d14904f..c7af4aa7dd6b 100644
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -356,10 +356,11 @@ int machine_kexec_prepare(struct kimage *image)
         * On those platforms the old kernel must reset TDX private
         * memory before jumping to the new kernel otherwise the new
         * kernel may see unexpected machine check.  For simplicity
-        * just fail kexec/kdump on those platforms.
+        * just fail kexec on those platforms.  Still allow kdump since
+        * the kdump kernel will only reads TDX memory but not write.
         */
-       if (boot_cpu_has_bug(X86_BUG_TDX_PW_MCE)) {
-               pr_info_once("Not allowed on platform with tdx_pw_mce
bug\n");
+       if (boot_cpu_has_bug(X86_BUG_TDX_PW_MCE) && image->type !=
KEXEC_TYPE_CRASH) {
+               pr_info_once("Kexec not allowed on platform with
tdx_pw_mce bug\n");
                return -EOPNOTSUPP;
        }