From: Dave Hansen <dave.hansen@intel.com>
To: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>,
"kirill.shutemov@linux.intel.com"
<kirill.shutemov@linux.intel.com>
Cc: "Huang, Kai" <kai.huang@intel.com>,
"ashish.kalra@amd.com" <ashish.kalra@amd.com>,
"dyoung@redhat.com" <dyoung@redhat.com>,
"thomas.lendacky@amd.com" <thomas.lendacky@amd.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Chatre, Reinette" <reinette.chatre@intel.com>,
"seanjc@google.com" <seanjc@google.com>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"nik.borisov@suse.com" <nik.borisov@suse.com>,
"bhe@redhat.com" <bhe@redhat.com>,
"Yamahata, Isaku" <isaku.yamahata@intel.com>,
"hpa@zytor.com" <hpa@zytor.com>,
"peterz@infradead.org" <peterz@infradead.org>,
"sagis@google.com" <sagis@google.com>,
"bp@alien8.de" <bp@alien8.de>,
"dwmw@amazon.co.uk" <dwmw@amazon.co.uk>,
"x86@kernel.org" <x86@kernel.org>,
"Williams, Dan J" <dan.j.williams@intel.com>
Subject: Re: [RFC PATCH 1/5] x86/kexec: Do unconditional WBINVD for bare-metal in stop_this_cpu()
Date: Wed, 19 Mar 2025 09:41:14 -0700 [thread overview]
Message-ID: <eb2e3b02-cf5e-4848-8f1d-9f3af8f9c96b@intel.com> (raw)
In-Reply-To: <c7cec9118a23220986c1894f18cafb3aa5b9fc1f.camel@intel.com>
On 3/17/25 14:59, Edgecombe, Rick P wrote:
> Sure, but non-selfsnoop CPUs can have trouble when PAT aliases cachetypes, I
> guess. This came up in KVM recently.
>
> So if new kernel maps the same memory with a different memtype I thought it
> might be a similar problem.
Yeah, both the KeyIDs and memtypes mismatches are places that normal
cache coherency breaks. They break it in different ways for sure, but
it's still broken in a way that software has to work around.
As for kexec vs. PAT memtypes, there are only even theoretical issues on
old hardware. They _theoretically_ need a WBINVD at kexec. But there
might be enough other things happening during kexec (including other
WBINVD's) to keep us from getting bitten in practice.
I'm not going to lose any sleep over it though.
next prev parent reply other threads:[~2025-03-19 16:42 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-12 11:34 [RFC PATCH 0/5] TDX host: kexec/kdump support Kai Huang
2025-03-12 11:34 ` [RFC PATCH 1/5] x86/kexec: Do unconditional WBINVD for bare-metal in stop_this_cpu() Kai Huang
2025-03-13 18:40 ` Edgecombe, Rick P
2025-03-14 10:03 ` Huang, Kai
2025-03-14 15:11 ` Tom Lendacky
2025-03-14 16:28 ` Edgecombe, Rick P
2025-03-14 18:18 ` Tom Lendacky
2025-03-14 18:57 ` Edgecombe, Rick P
2025-03-17 10:11 ` Huang, Kai
2025-03-18 3:41 ` Edgecombe, Rick P
2025-03-20 0:03 ` Huang, Kai
2025-03-17 12:52 ` kirill.shutemov
2025-03-17 21:59 ` Edgecombe, Rick P
2025-03-19 16:41 ` Dave Hansen [this message]
2025-03-19 17:03 ` Edgecombe, Rick P
2025-03-19 21:42 ` Huang, Kai
2025-03-12 11:34 ` [RFC PATCH 2/5] x86/kexec: Do unconditional WBINVD for bare-metal in relocate_kernel() Kai Huang
2025-03-13 23:17 ` Edgecombe, Rick P
2025-03-14 9:44 ` Huang, Kai
2025-03-18 3:54 ` Edgecombe, Rick P
2025-03-19 9:57 ` Huang, Kai
2025-03-19 16:20 ` Edgecombe, Rick P
2025-03-12 11:34 ` [RFC PATCH 3/5] x86/kexec: Disable kexec/kdump on platforms with TDX partial write erratum Kai Huang
2025-03-12 23:27 ` Edgecombe, Rick P
2025-03-13 0:57 ` Huang, Kai
2025-03-13 17:18 ` Edgecombe, Rick P
2025-03-13 22:32 ` Huang, Kai
2025-03-13 22:47 ` Edgecombe, Rick P
2025-03-13 23:57 ` Huang, Kai
2025-03-14 19:03 ` Edgecombe, Rick P
2025-03-17 1:19 ` Huang, Kai
2025-03-17 23:53 ` Edgecombe, Rick P
2025-03-12 11:34 ` [RFC PATCH 4/5] x86/virt/tdx: Remove the !KEXEC_CORE dependency Kai Huang
2025-03-12 11:34 ` [RFC PATCH 5/5] x86/virt/tdx: Update the kexec section in the TDX documentation Kai Huang
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=eb2e3b02-cf5e-4848-8f1d-9f3af8f9c96b@intel.com \
--to=dave.hansen@intel.com \
--cc=ashish.kalra@amd.com \
--cc=bhe@redhat.com \
--cc=bp@alien8.de \
--cc=dan.j.williams@intel.com \
--cc=dwmw@amazon.co.uk \
--cc=dyoung@redhat.com \
--cc=hpa@zytor.com \
--cc=isaku.yamahata@intel.com \
--cc=kai.huang@intel.com \
--cc=kirill.shutemov@linux.intel.com \
--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=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
all inboxes | Powered by JetHome®