public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/7] x86/microcode: Refactor NMI-based rendezvous mechanism to stop-machine
@ 2026-01-25  1:42 Chang S. Bae
  2026-01-25  1:42 ` [PATCH 1/7] stop_machine: Introduce stop_machine_nmi() Chang S. Bae
                   ` (6 more replies)
  0 siblings, 7 replies; 28+ messages in thread
From: Chang S. Bae @ 2026-01-25  1:42 UTC (permalink / raw)
  To: linux-kernel
  Cc: x86, tglx, mingo, bp, dave.hansen, peterz, david.kaplan,
	chang.seok.bae

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


^ permalink raw reply	[flat|nested] 28+ messages in thread

end of thread, other threads:[~2026-03-04 16:34 UTC | newest]

Thread overview: 28+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-01-25  1:42 [PATCH 0/7] x86/microcode: Refactor NMI-based rendezvous mechanism to stop-machine Chang S. Bae
2026-01-25  1:42 ` [PATCH 1/7] stop_machine: Introduce stop_machine_nmi() Chang S. Bae
2026-01-26 11:51   ` kernel test robot
2026-01-27 14:49     ` Borislav Petkov
2026-01-27 19:15       ` Chang S. Bae
2026-01-27 15:49   ` Borislav Petkov
2026-01-27 16:00     ` Kaplan, David
2026-01-27 20:49       ` Borislav Petkov
2026-01-28  1:31         ` Kaplan, David
2026-01-28 16:35           ` Borislav Petkov
2026-01-29 12:17             ` Borislav Petkov
2026-01-29 15:47               ` Chang S. Bae
2026-02-02 10:54               ` Borislav Petkov
2026-02-06  2:14                 ` Chang S. Bae
2026-03-04 16:33                   ` Borislav Petkov
2026-01-28  8:02   ` Thomas Gleixner
2026-01-29 17:07     ` Chang S. Bae
2026-01-30 10:02       ` Thomas Gleixner
2026-01-25  1:42 ` [PATCH 2/7] x86/apic: Implement self-NMI support Chang S. Bae
2026-01-28  8:05   ` Thomas Gleixner
2026-01-29 16:32     ` Chang S. Bae
2026-01-25  1:42 ` [PATCH 3/7] x86/nmi: Support stop_machine_nmi() handler Chang S. Bae
2026-01-25  1:42 ` [PATCH 4/7] x86/microcode: Distinguish NMI control path on stop-machine callback Chang S. Bae
2026-01-28  8:11   ` Thomas Gleixner
2026-01-29 16:32     ` Chang S. Bae
2026-01-25  1:42 ` [PATCH 5/7] x86/microcode: Use stop-machine NMI facility Chang S. Bae
2026-01-25  1:42 ` [PATCH 6/7] x86/nmi: Reference stop-machine static key for offline microcode handler Chang S. Bae
2026-01-25  1:42 ` [PATCH 7/7] x86/microcode: Remove microcode_nmi_handler_enable Chang S. Bae

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox