Re: [RFC PATCH 1/5] x86/kexec: Do unconditional WBINVD for bare-metal in stop_this_cpu()
From: Edgecombe, Rick P
Date: Fri Mar 14 2025 - 12:29:14 EST
On Fri, 2025-03-14 at 10:11 -0500, Tom Lendacky wrote:
> > I see that this already has Tom's RB, but I'm not sure how this works for
> > AMD.
> > The original SME patch tried to avoid writing to memory by putting the
> > wbinvd
> > immediately before the halt, but today it is further away. Below this hunk
> > there
> > are more instructions that could dirty memory before the halt. Ohh... it's
> > new.
> > 9 months ago 26ba7353caaa ("x86/smp: Add smp_ops.stop_this_cpu() callback")
> > adds
> > a function call that would touch the stack. I think it's wrong? And probably
> > introduced after this patch was originally written.
> >
> > Then the cpuid_eax() could be non-inlined, but probably not. But the
> > boot_cpu_has() added in this patch could call out to kasan and dirty the
> > stack.
> >
> > So I think the existing SME case might be theoretically incorrect, and if so
> > this makes things very slightly worse.
>
> But the wbinvd() is performed after those checks, so everything gets flushed.
Oh, right, duh. Thanks for checking. Yea those shouldn't matter.
Does the stop_this_cpu() part never come into play for SME either? It looks like
it was added for TDX guest kexec, but is a general ACPI thing.
Regarding the kasan thing, I was looking at this too:
wbinvd()
cpumask_clear_cpu()
clear_bit()
instrument_atomic_write()
kasan_check_write()
__kasan_check_write() <- non-inline