From: "Chang S. Bae" <chang.seok.bae@intel.com>
To: linux-kernel@vger.kernel.org
Cc: x86@kernel.org, tglx@kernel.org, mingo@redhat.com, bp@alien8.de,
dave.hansen@linux.intel.com, peterz@infradead.org,
david.kaplan@amd.com, chang.seok.bae@intel.com
Subject: [PATCH v3 5/9] x86/nmi: Support NMI stop-machine handler
Date: Thu, 15 Oct 2026 21:14:22 +0000 [thread overview]
Message-ID: <20261015211426.49114-6-chang.seok.bae@intel.com> (raw)
In-Reply-To: <20261015211426.49114-1-chang.seok.bae@intel.com>
From: David Kaplan <david.kaplan@amd.com>
Call the stop-machine handler from the NMI path in order to support the
NMI stop-machine.
Signed-off-by: David Kaplan <david.kaplan@amd.com>
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
---
Sashiko raises a concern about coalescing edge-triggered events, such as
PMU overflows. But, not sure whether a practical issue or not especially
with this stop-machine use.
The current use of this facility has been to the microcode loader. Then
the mentioned case sounds like somewhat careless setup. Thus, the concern
looks theoretical, leaving the handling as-is.
---
arch/x86/kernel/nmi.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/x86/kernel/nmi.c b/arch/x86/kernel/nmi.c
index 3c9f60d6ca5a..26f5ca1ac8a5 100644
--- a/arch/x86/kernel/nmi.c
+++ b/arch/x86/kernel/nmi.c
@@ -24,6 +24,7 @@
#include <linux/export.h>
#include <linux/atomic.h>
#include <linux/sched/clock.h>
+#include <linux/stop_machine.h>
#include <linux/kvm_types.h>
#include <asm/cpu_entry_area.h>
@@ -382,6 +383,9 @@ static noinstr void default_do_nmi(struct pt_regs *regs)
instrumentation_begin();
+ if (stop_machine_nmi_handler())
+ goto out;
+
if (microcode_nmi_handler_enabled() && microcode_nmi_handler())
goto out;
--
2.53.0
next prev parent reply other threads:[~2026-10-15 21:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-15 21:14 [PATCH v3 0/9] x86/microcode: Refactor NMI-based rendezvous mechanism to stop-machine Chang S. Bae
2026-10-15 21:14 ` [PATCH v3 1/9] stop_machine: Refactor multi-CPU stop glue code Chang S. Bae
2026-10-15 21:14 ` [PATCH v3 2/9] stop_machine: Add NMI-based execution path Chang S. Bae
2026-10-15 21:14 ` [PATCH v3 3/9] stop_machine: Introduce stop_machine_nmi_cpuslocked() Chang S. Bae
2026-10-16 7:15 ` kernel test robot
2026-10-15 21:14 ` [PATCH v3 4/9] x86/apic: Implement self-NMI support Chang S. Bae
2026-10-15 21:14 ` Chang S. Bae [this message]
2026-10-15 21:14 ` [PATCH v3 6/9] x86/microcode: Distinguish NMI control path on stop-machine callback Chang S. Bae
2026-10-15 21:14 ` [PATCH v3 7/9] x86/microcode: Use stop-machine NMI facility Chang S. Bae
2026-10-15 21:14 ` [PATCH v3 8/9] x86/nmi: Simplify offline microcode handler invocation Chang S. Bae
2026-10-15 21:14 ` [PATCH v3 9/9] x86/microcode: Remove microcode_nmi_handler_enable Chang S. Bae
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261015211426.49114-6-chang.seok.bae@intel.com \
--to=chang.seok.bae@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=david.kaplan@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®