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 - 14:57:27 EST
On Fri, 2025-03-14 at 13:18 -0500, Tom Lendacky wrote:
> > 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.
>
> It is a general ACPI thing, but I don't know of it being used by our MADT
> tables.
>
> >
> > 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
>
> Yes, this does look worrisome. Too bad there isn't a way to turn off KASAN
> for a single function.
I wonder why that one has an explicit call, compared to compiler generated
stuff. It makes me wonder if there is just some KASAN skipping bit-wise
operations that could be done to fix it.
For stop_this_cpu(), not sure how to avoid it. Maybe just a raw jump to the
function pointer or something. It's not supposed to return. If it is actually
not an issue due foreseeable lack of real world HW/firmware, a comment would be
nice touch.
Ok, well based on your earlier point, the new code actually doesn't make things
worse for SME. For TDX the late function calls are not a problem. So we'll leave
it to you guys.
Thanks for responding so quickly.