[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260125014224.249901-1-chang.seok.bae@intel.com>
Date: Sun, 25 Jan 2026 01:42:15 +0000
From: "Chang S. Bae" <chang.seok.bae@...el.com>
To: linux-kernel@...r.kernel.org
Cc: x86@...nel.org,
tglx@...utronix.de,
mingo@...hat.com,
bp@...en8.de,
dave.hansen@...ux.intel.com,
peterz@...radead.org,
david.kaplan@....com,
chang.seok.bae@...el.com
Subject: [PATCH 0/7] x86/microcode: Refactor NMI-based rendezvous mechanism to stop-machine
Hi all,
David Kaplan previously proposed introducing an NMI-based stop-machine
mechanism as part of his dynamic mitigation series [1]. This "big hammer"
approach was also discussed during the last LPC x86 uconf [2].
This patchset uses the facility for the late-loading of Intel microcode
by refactoring existing NMI control mechanism. There is one bit to call
out for the review here -- offline CPU handling. Before highlighting the
case, let me first walk through the online case:
== Online CPU Handling ==
Currently, the microcode loader uses a NMI-based control flow, similar
to the proposed stop_machine_nmi(). When the NMI option is enabled, the
loader invokes stop-machine, and the callback establishes an IPI back to
the local CPU, which then performs the microcode update from NMI context.
Per-CPU flags are used throughout to ensure correct handling.
The new facility directly incorporates this existing control logic, with
the following components in place (mostly in PATCH1 unless noted
otherwise):
1. A static key indicating the global window of stop-machine execution
during rendezvous
2. A control mechanism to fire NMIs and invoke a custom handler from
the NMI path, implemented in architecture-specific code (PATCH2/3)
3. A per-CPU notion of an active NMI handling window
Given this, it is natural to convert this to use the generic
stop_machine_nmi().
== Offline CPU Handling ==
With NMI-based microcode loading, soft-offlined CPUs are also brought
into the rendezvous to avoid unexpected behavior changes (e.g. related
to MWAIT) introduced by new microcode [3].
Today, the boot CPU explicitly fires IPIs to those offline CPUs, which
establishes yet another NMI control path. However, the new stop-machine
facility does not currently account for this case, as it is primarily
shaped for online CPUs.
This patch set is intended to introduce stop_machine_nmi() along with an
existing use case (Intel ucode late-loading), independent of the dynamic
mitigation series.
The commonality, nonetheless, between them lies on online CPU handling.
So, it was considered to make sense that the static key is just reused to
condition offline CPU handling as well (PATCH6).
== Patch Structure ==
* PATCH 1–3: Establish the stop-machine NMI facility (pretty much those
PATCH29–31 of the dynamic mitigation series [1])
* PATCH 4–7: Incremental refactoring, with offline handling update.
The patch set is available in this repository:
git://github.com/intel-staging/microcode.git nmi-stop-machine
Testing was performed using late-loading on Intel CPUs, which default to
the NMI-based update path.
Thanks,
Chang
[1]: https://lore.kernel.org/lkml/20251013143444.3999-1-david.kaplan@amd.com/
[2]: https://youtu.be/2eEPYt5XrCE?si=NUGF2pkqk8MUh9GR&t=1739
[3]: 8f849ff63bcb ("x86/microcode: Handle "offline" CPUs correctly")
Chang S. Bae (4):
x86/microcode: Distinguish NMI control path on stop-machine callback
x86/microcode: Use stop-machine NMI facility
x86/nmi: Reference stop-machine static key for offline microcode
handler
x86/microcode: Remove microcode_nmi_handler_enable
David Kaplan (3):
stop_machine: Introduce stop_machine_nmi()
x86/apic: Implement self-NMI support
x86/nmi: Support stop_machine_nmi() handler
arch/x86/include/asm/microcode.h | 11 +---
arch/x86/kernel/apic/ipi.c | 7 +++
arch/x86/kernel/cpu/microcode/core.c | 35 +++---------
arch/x86/kernel/nmi.c | 7 ++-
include/linux/stop_machine.h | 50 +++++++++++++++++
kernel/stop_machine.c | 84 ++++++++++++++++++++++++++--
6 files changed, 150 insertions(+), 44 deletions(-)
base-commit: 24d479d26b25bce5faea3ddd9fa8f3a6c3129ea7
--
2.51.0
Powered by blists - more mailing lists