From: Dave Hansen <dave.hansen@intel.com>
To: Vishal Annapurve <vannapurve@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org, bp@alien8.de,
tglx@linutronix.de, peterz@infradead.org, mingo@redhat.com,
hpa@zytor.com, thomas.lendacky@amd.com, x86@kernel.org,
kas@kernel.org, rick.p.edgecombe@intel.com, dwmw@amazon.co.uk,
kai.huang@intel.com, seanjc@google.com,
reinette.chatre@intel.com, isaku.yamahata@intel.com,
dan.j.williams@intel.com, ashish.kalra@amd.com,
nik.borisov@suse.com, chao.gao@intel.com, sagis@google.com,
farrah.chen@intel.com, Binbin Wu <binbin.wu@linux.intel.com>
Subject: Re: [PATCH 4/7] x86/kexec: Disable kexec/kdump on platforms with TDX partial write erratum
Date: Wed, 1 Oct 2025 07:32:21 -0700 [thread overview]
Message-ID: <a2042a7b-2e12-4893-ac8d-50c0f77f26e9@intel.com> (raw)
In-Reply-To: <CAGtprH-mb0Cw+OzBj-gSWenA9kSJyu-xgXhsTjjzyY6Qi4E=aw@mail.gmail.com>
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.
next prev parent reply other threads:[~2025-10-01 14:32 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-01 16:09 [PATCH v8 0/7] TDX host: kexec/kdump support Paolo Bonzini
2025-09-01 16:09 ` [PATCH 1/7] x86/kexec: Consolidate relocate_kernel() function parameters Paolo Bonzini
2025-09-01 16:09 ` [PATCH 2/7] x86/sme: Use percpu boolean to control WBINVD during kexec Paolo Bonzini
2025-09-01 16:09 ` [PATCH 3/7] x86/virt/tdx: Mark memory cache state incoherent when making SEAMCALL Paolo Bonzini
2025-09-01 16:09 ` [PATCH 4/7] x86/kexec: Disable kexec/kdump on platforms with TDX partial write erratum Paolo Bonzini
2025-09-30 1:38 ` Vishal Annapurve
2025-09-30 21:32 ` Dave Hansen
2025-10-01 2:05 ` Vishal Annapurve
2025-10-01 14:32 ` Dave Hansen [this message]
2025-10-01 17:17 ` Vishal Annapurve
2025-10-01 18:00 ` Dave Hansen
2025-10-01 21:19 ` Huang, Kai
2025-10-02 6:59 ` Reshetova, Elena
2025-10-02 7:46 ` Juergen Gross
2025-10-02 8:10 ` Reshetova, Elena
2025-10-02 15:06 ` Dave Hansen
2025-10-02 16:09 ` Vishal Annapurve
2025-10-18 15:54 ` Vishal Annapurve
2025-10-21 17:08 ` Dave Hansen
2025-10-22 2:50 ` Vishal Annapurve
2025-10-22 21:05 ` Huang, Kai
2025-10-23 16:54 ` Vishal Annapurve
2025-10-07 13:31 ` Jürgen Groß
2025-10-08 15:40 ` Dave Hansen
2025-10-08 18:13 ` Jürgen Groß
2025-10-26 23:33 ` Vishal Annapurve
2025-10-27 0:50 ` Huang, Kai
2025-10-27 16:23 ` Edgecombe, Rick P
2025-10-27 21:28 ` Huang, Kai
2025-10-28 0:07 ` Vishal Annapurve
2025-10-28 9:31 ` Huang, Kai
2025-11-03 16:44 ` Vishal Annapurve
2025-09-01 16:09 ` [PATCH 5/7] x86/virt/tdx: Remove the !KEXEC_CORE dependency Paolo Bonzini
2025-09-01 16:09 ` [PATCH 6/7] x86/virt/tdx: Update the kexec section in the TDX documentation Paolo Bonzini
2025-09-01 16:09 ` [PATCH 7/7] KVM: TDX: Explicitly do WBINVD when no more TDX SEAMCALLs Paolo Bonzini
2025-10-03 13:09 ` [PATCH v8 0/7] TDX host: kexec/kdump support Paolo Bonzini
2025-10-03 13:54 ` David Woodhouse
2025-10-03 14:05 ` Dave Hansen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a2042a7b-2e12-4893-ac8d-50c0f77f26e9@intel.com \
--to=dave.hansen@intel.com \
--cc=ashish.kalra@amd.com \
--cc=binbin.wu@linux.intel.com \
--cc=bp@alien8.de \
--cc=chao.gao@intel.com \
--cc=dan.j.williams@intel.com \
--cc=dwmw@amazon.co.uk \
--cc=farrah.chen@intel.com \
--cc=hpa@zytor.com \
--cc=isaku.yamahata@intel.com \
--cc=kai.huang@intel.com \
--cc=kas@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=nik.borisov@suse.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=reinette.chatre@intel.com \
--cc=rick.p.edgecombe@intel.com \
--cc=sagis@google.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=vannapurve@google.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox