From: Sohil Mehta <sohil.mehta@intel.com>
To: x86@kernel.org, linux-kernel@vger.kernel.org
Cc: Xin Li <xin@zytor.com>, "H . Peter Anvin" <hpa@zytor.com>,
Andy Lutomirski <luto@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
Peter Zijlstra <peterz@infradead.org>,
Sean Christopherson <seanjc@google.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
Kan Liang <kan.liang@linux.intel.com>,
Tony Luck <tony.luck@intel.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
"Rafael J . Wysocki" <rafael@kernel.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Zhang Rui <rui.zhang@intel.com>,
Lukasz Luba <lukasz.luba@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Sohil Mehta <sohil.mehta@intel.com>,
Brian Gerst <brgerst@gmail.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
Jacob Pan <jacob.pan@linux.microsoft.com>,
Andi Kleen <ak@linux.intel.com>, Kai Huang <kai.huang@intel.com>,
Nikolay Borisov <nik.borisov@suse.com>,
linux-perf-users@vger.kernel.org, linux-edac@vger.kernel.org,
kvm@vger.kernel.org, linux-pm@vger.kernel.org,
linux-trace-kernel@vger.kernel.org
Subject: [PATCH v5 5/9] x86/nmi: Add support to handle NMIs with source information
Date: Tue, 6 May 2025 18:21:41 -0700 [thread overview]
Message-ID: <20250507012145.2998143-6-sohil.mehta@intel.com> (raw)
In-Reply-To: <20250507012145.2998143-1-sohil.mehta@intel.com>
The NMI-source bitmap is delivered as FRED event data to the kernel.
When available, use NMI-source based filtering to determine the exact
handlers to run.
Activate NMI-source based filtering only for Local NMIs. While handling
platform NMI types (such as SERR and IOCHK), do not use the source
bitmap. They have only one handler registered per type, so there is no
need to disambiguate between multiple handlers.
Some third-party chipsets may send NMI messages with a hardcoded vector
of 2, which would result in bit 2 being set in the NMI-source bitmap.
Skip the local NMI handlers in this situation.
Bit 0 of the source bitmap is set by the hardware whenever a source
vector was not used while generating an NMI, or the originator could not
be reliably identified. Poll all the registered handlers in that case.
When multiple handlers need to be executed, adhere to the existing
priority scheme and execute the handlers registered with NMI_FLAG_FIRST
before others.
The logic for handling legacy NMIs is unaffected since the source bitmap
would always be zero.
Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
---
v5: Significantly simplify NMI-source handling logic.
Get rid of a separate lookup table for NMI-source vectors.
Adhere to existing priority scheme for handling NMIs.
---
arch/x86/kernel/nmi.c | 40 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/arch/x86/kernel/nmi.c b/arch/x86/kernel/nmi.c
index a1d672dcb6f0..183e3e717326 100644
--- a/arch/x86/kernel/nmi.c
+++ b/arch/x86/kernel/nmi.c
@@ -127,9 +127,25 @@ static void nmi_check_duration(struct nmiaction *action, u64 duration)
action->handler, duration, decimal_msecs);
}
+/*
+ * Match the NMI-source vector saved during registration with the source
+ * bitmap.
+ *
+ * Always return true when bit 0 of the source bitmap is set.
+ */
+static inline bool match_nmi_source(unsigned long source_bitmap, struct nmiaction *action)
+{
+ unsigned long match_vector;
+
+ match_vector = BIT(NMIS_VECTOR_NONE) | BIT(action->source_vector);
+
+ return (source_bitmap & match_vector);
+}
+
static int nmi_handle(unsigned int type, struct pt_regs *regs)
{
struct nmi_desc *desc = nmi_to_desc(type);
+ unsigned long source_bitmap = 0;
nmi_handler_t ehandler;
struct nmiaction *a;
int handled=0;
@@ -148,16 +164,40 @@ static int nmi_handle(unsigned int type, struct pt_regs *regs)
rcu_read_lock();
+ /*
+ * Activate NMI source-based filtering only for Local NMIs.
+ *
+ * Platform NMI types (such as SERR and IOCHK) have only one
+ * handler registered per type, so there is no need to
+ * disambiguate between multiple handlers.
+ *
+ * Also, if a platform source ends up setting bit 2 in the
+ * source bitmap, the local NMI handlers would be skipped since
+ * none of them use this reserved vector.
+ *
+ * For Unknown NMIs, avoid using the source bitmap to ensure all
+ * potential handlers have a chance to claim responsibility.
+ */
+ if (cpu_feature_enabled(X86_FEATURE_NMI_SOURCE) && type == NMI_LOCAL)
+ source_bitmap = fred_event_data(regs);
+
/*
* NMIs are edge-triggered, which means if you have enough
* of them concurrently, you can lose some because only one
* can be latched at any given time. Walk the whole list
* to handle those situations.
+ *
+ * However, NMI-source reporting does not have this limitation.
+ * When NMI-source information is available, only run the
+ * handlers that match the reported vectors.
*/
list_for_each_entry_rcu(a, &desc->head, list) {
int thishandled;
u64 delta;
+ if (source_bitmap && !match_nmi_source(source_bitmap, a))
+ continue;
+
delta = sched_clock();
thishandled = a->handler(type, regs);
handled += thishandled;
--
2.43.0
next prev parent reply other threads:[~2025-05-07 1:21 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-07 1:21 [PATCH v5 0/9] x86: Add support for NMI-source reporting with FRED Sohil Mehta
2025-05-07 1:21 ` [PATCH v5 1/9] x86/fred, KVM: VMX: Pass event data to the FRED entry point from KVM Sohil Mehta
2025-05-07 1:21 ` [PATCH v5 2/9] x86/cpufeatures: Add the CPUID feature bit for NMI-source reporting Sohil Mehta
2025-05-07 1:21 ` [PATCH v5 3/9] x86/nmi: Extend the registration interface to include the NMI-source vector Sohil Mehta
2025-05-07 1:21 ` [PATCH v5 4/9] x86/nmi: Assign and register NMI-source vectors Sohil Mehta
2025-05-07 8:22 ` Peter Zijlstra
2025-05-07 20:43 ` Sohil Mehta
2025-05-07 1:21 ` Sohil Mehta [this message]
2025-05-07 9:14 ` [PATCH v5 5/9] x86/nmi: Add support to handle NMIs with source information Peter Zijlstra
2025-05-07 21:48 ` Sohil Mehta
2025-05-08 12:15 ` Peter Zijlstra
2025-05-08 20:23 ` H. Peter Anvin
2025-05-08 20:49 ` Peter Zijlstra
2025-05-09 0:45 ` Sohil Mehta
2025-05-07 1:21 ` [PATCH v5 6/9] x86/nmi: Prepare for the new NMI-source vector encoding Sohil Mehta
2025-05-07 9:17 ` Peter Zijlstra
2025-05-07 22:10 ` Sohil Mehta
2025-05-07 1:21 ` [PATCH v5 7/9] x86/nmi: Enable NMI-source for IPIs delivered as NMIs Sohil Mehta
2025-05-07 1:21 ` [PATCH v5 8/9] perf/x86: Enable NMI-source reporting for perfmon Sohil Mehta
2025-05-08 11:20 ` Sandipan Das
2025-05-09 0:46 ` Sohil Mehta
2025-05-07 1:21 ` [PATCH v5 9/9] x86/nmi: Include NMI-source information in tracepoint and debug prints Sohil Mehta
2025-05-07 21:48 ` Steven Rostedt
2025-05-08 0:02 ` Sohil Mehta
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=20250507012145.2998143-6-sohil.mehta@intel.com \
--to=sohil.mehta@intel.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=andrew.cooper3@citrix.com \
--cc=bp@alien8.de \
--cc=brgerst@gmail.com \
--cc=daniel.lezcano@linaro.org \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=irogers@google.com \
--cc=jacob.pan@linux.microsoft.com \
--cc=jolsa@kernel.org \
--cc=kai.huang@intel.com \
--cc=kan.liang@linux.intel.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=lukasz.luba@arm.com \
--cc=luto@kernel.org \
--cc=mark.rutland@arm.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=nik.borisov@suse.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=rostedt@goodmis.org \
--cc=rui.zhang@intel.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=vkuznets@redhat.com \
--cc=x86@kernel.org \
--cc=xin@zytor.com \
/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