[PATCH 0/7] x86/microcode: Refactor NMI-based rendezvous mechanism to stop-machine

["Chang S. Bae" <chang.seok.bae@intel.com>]

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