On Wed, Mar 20, 2024 at 10:20:50AM +1300, Huang, Kai wrote:
On 20/03/2024 3:38 am, Tom Lendacky wrote:
On 3/19/24 06:13, Kirill A. Shutemov wrote:
On Tue, Mar 19, 2024 at 01:48:45AM +0000, Kai Huang wrote:
Both SME and TDX can leave caches in incoherent state due to memory
encryption. During kexec, the caches must be flushed before jumping to
the second kernel to avoid silent memory corruption to the
second kernel.
During kexec, the WBINVD in stop_this_cpu() flushes caches for all
remote cpus when they are being stopped. For SME, the WBINVD in
relocate_kernel() flushes the cache for the last running cpu (which is
executing the kexec).
Similarly, for TDX after stopping all remote cpus with cache flushed, to
support kexec, the kernel needs to flush cache for the last running cpu.
Make the WBINVD in the relocate_kernel() unconditional to cover both SME
and TDX.
Nope. It breaks TDX guest. WBINVD triggers #VE for TDX guests.
Ditto for SEV-ES/SEV-SNP, a #VC is generated and crashes the guest.
Oh I forgot these.
Hi Kirill,
Then I think patch 1 will also break TDX guest after your series to enable
multiple cpus for the second kernel after kexec()?
Well, not exactly.
My patchset overrides stop_this_cpu() with own implementation for MADT
wakeup method that doesn't have WBINVD. So the patch doesn't break
anything,
method instead of IPI we will get back to the problem with missing
WBINVD.
I don't know if we care. There's no reason for host to use MADT wake up
method.