Re: [RFC PATCH 40/56] x86/alternative: Use sync_core_nmi_safe()

David Laight
2025-10-23T21:23:36Z

On Mon, 20 Oct 2025 17:01:33 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Mon, Oct 20, 2025 at 02:49:56PM +0000, Kaplan, David wrote:
>
> > Coming back to this, are you thinking we should just create something
> > like 'text_poke_sync_core()' inside alternative.c and that can use:
> > 1. SERIALIZE (if available)
> > 2. MOV-CR2 (if re-patching)
> > 3. Else, IRET
> >
> > And maybe someday we put MFENCE into there too for AMD parts.
> >
> > Right now, of course this is the only logic that would care about an
> > NMI-safe sync_core(). So maybe this makes sense vs creating a generic
> > version that nobody else is using?
>
> I was thinking something fairly straight forward like the below. Yes,
> there are a few more sync_core() callers out there, git tells me:
>
...
> But none of that seems like it cares about an extra few cycles, and why
> complicate matters with another sync_core variant and all that.
>
...
> + * CPUID is the conventional way, but it's nasty: it doesn't
> + * exist on some 486-like CPUs, and it usually exits to a
> + * hypervisor.

Hasn't support for those 486 cpu been dropped now?
So the comment probably needs updating?

David