From: Jacob Pan <jacob.jun.pan@linux.intel.com>
To: X86 Kernel <x86@kernel.org>,
Sean Christopherson <seanjc@google.com>,
LKML <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Dave Hansen <dave.hansen@intel.com>,
"H. Peter Anvin" <hpa@zytor.com>,
"Ingo Molnar" <mingo@redhat.com>,
"Borislav Petkov" <bp@alien8.de>, "Xin Li" <xin3.li@intel.com>,
linux-perf-users@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Tony Luck <tony.luck@intel.com>,
Andy Lutomirski <luto@kernel.org>,
acme@kernel.org, kan.liang@linux.intel.com,
Andi Kleen <andi.kleen@intel.com>,
"Mehta, Sohil" <sohil.mehta@intel.com>,
Jacob Pan <jacob.jun.pan@linux.intel.com>
Subject: [PATCH v3 05/11] x86/irq: Process nmi sources in NMI handler
Date: Fri, 28 Jun 2024 13:18:33 -0700 [thread overview]
Message-ID: <20240628201839.673086-6-jacob.jun.pan@linux.intel.com> (raw)
In-Reply-To: <20240628201839.673086-1-jacob.jun.pan@linux.intel.com>
With NMI source reporting enabled, NMI handler can prioritize the
handling of sources reported explicitly. If the source is unknown, then
resume the existing processing flow. i.e. invoke all NMI handlers.
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
---
v3:
- Use a static flag to disable NMIs in case of HW failure
- Optimize the case when unknown NMIs are mixed with known NMIs(HPA)
v2:
- Disable NMI source reporting once garbage data is given in FRED
return stack. (HPA)
---
arch/x86/kernel/nmi.c | 73 +++++++++++++++++++++++++++++++++++++++++--
1 file changed, 70 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/nmi.c b/arch/x86/kernel/nmi.c
index 639a34e78bc9..c3a10af7f26b 100644
--- a/arch/x86/kernel/nmi.c
+++ b/arch/x86/kernel/nmi.c
@@ -149,23 +149,90 @@ static inline int do_handle_nmi(struct nmiaction *a, struct pt_regs *regs, unsig
return thishandled;
}
+static int nmi_handle_src(unsigned int type, struct pt_regs *regs, unsigned long *handled_mask)
+{
+ static bool nmi_source_disabled;
+ bool has_unknown_src = false;
+ unsigned long source_bitmask;
+ struct nmiaction *a;
+ int handled = 0;
+ int vec = 1;
+
+ if (!cpu_feature_enabled(X86_FEATURE_NMI_SOURCE) ||
+ type != NMI_LOCAL || nmi_source_disabled)
+ return 0;
+
+ source_bitmask = fred_event_data(regs);
+ if (!source_bitmask) {
+ pr_warn("NMI received without source information! Disable source reporting.\n");
+ nmi_source_disabled = true;
+ return 0;
+ }
+
+ /*
+ * Per NMI source specification, there is no guarantee that a valid
+ * NMI vector is always delivered, even when the source specified
+ * one. It is software's responsibility to check all available NMI
+ * sources when bit 0 is set in the NMI source bitmap. i.e. we have
+ * to call every handler as if we have no NMI source.
+ * On the other hand, if we do get non-zero vectors, we know exactly
+ * what the sources are. So we only call the handlers with the bit set.
+ */
+ if (source_bitmask & BIT(NMI_SOURCE_VEC_UNKNOWN)) {
+ pr_warn_ratelimited("NMI received with unknown source\n");
+ has_unknown_src = true;
+ }
+
+ rcu_read_lock();
+ /* Bit 0 is for unknown NMI sources, skip it. */
+ for_each_set_bit_from(vec, &source_bitmask, NR_NMI_SOURCE_VECTORS) {
+ a = rcu_dereference(nmiaction_src_table[vec]);
+ if (!a) {
+ pr_warn_ratelimited("NMI received %d no handler", vec);
+ continue;
+ }
+ handled += do_handle_nmi(a, regs, type);
+ /*
+ * Needs polling if unknown source bit is set, handled_mask is
+ * used to tell the polling code which NMIs can be skipped.
+ */
+ if (has_unknown_src)
+ *handled_mask |= BIT(vec);
+ }
+ rcu_read_unlock();
+
+ return handled;
+}
+
static int nmi_handle(unsigned int type, struct pt_regs *regs)
{
struct nmi_desc *desc = nmi_to_desc(type);
+ unsigned long handled_mask = 0;
struct nmiaction *a;
int handled=0;
- rcu_read_lock();
+ /*
+ * Check if the NMI source handling is complete, otherwise polling is
+ * still required. handled_mask is non-zero if NMI source handling is
+ * partial due to unknown NMI sources.
+ */
+ handled = nmi_handle_src(type, regs, &handled_mask);
+ if (handled && !handled_mask)
+ return handled;
+ rcu_read_lock();
/*
* 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.
*/
- list_for_each_entry_rcu(a, &desc->head, list)
+ list_for_each_entry_rcu(a, &desc->head, list) {
+ /* Skip NMIs handled earlier with source info */
+ if (BIT(a->source_vec) & handled_mask)
+ continue;
handled += do_handle_nmi(a, regs, type);
-
+ }
rcu_read_unlock();
/* return total number of NMI events handled */
--
2.25.1
next prev parent reply other threads:[~2024-06-28 20:13 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-28 20:18 [PATCH v3 00/11] Add support for NMI source reporting Jacob Pan
2024-06-28 20:18 ` [PATCH v3 01/11] x86/irq: Add enumeration of NMI source reporting CPU feature Jacob Pan
2024-06-28 20:18 ` [PATCH v3 02/11] x86/irq: Define NMI source vectors Jacob Pan
2024-06-29 18:32 ` Xin Li
2024-07-01 17:16 ` Jacob Pan
2024-06-28 20:18 ` [PATCH v3 03/11] x86/irq: Extend NMI handler registration interface to include source Jacob Pan
2024-06-28 20:18 ` [PATCH v3 04/11] x86/irq: Factor out common NMI handling code Jacob Pan
2024-06-29 0:31 ` Xin Li
2024-07-03 23:10 ` Jacob Pan
2024-06-28 20:18 ` Jacob Pan [this message]
2024-06-29 3:39 ` [PATCH v3 05/11] x86/irq: Process nmi sources in NMI handler Xin Li
2024-07-07 3:48 ` Jacob Pan
2024-07-01 14:31 ` Nikolay Borisov
2024-07-01 15:36 ` Jacob Pan
2024-06-28 20:18 ` [PATCH v3 06/11] KVM: VMX: Expand FRED kvm entry with event data Jacob Pan
2024-06-29 4:01 ` Xin Li
2024-07-01 15:39 ` Jacob Pan
2024-06-28 20:18 ` [PATCH v3 07/11] KVM: VMX: Handle NMI Source report in VM exit Jacob Pan
2024-06-29 4:07 ` Xin Li
2024-07-01 15:45 ` Jacob Pan
2024-07-01 17:03 ` Xin Li
2024-07-01 18:00 ` Jacob Pan
2024-06-30 13:04 ` Zeng Guang
2024-07-01 15:46 ` Jacob Pan
2024-06-28 20:18 ` [PATCH v3 08/11] perf/x86: Enable NMI source reporting for perfmon Jacob Pan
2024-07-04 14:44 ` Liang, Kan
2024-07-06 22:49 ` Jacob Pan
2024-06-28 20:18 ` [PATCH v3 09/11] x86/irq: Enable NMI source on IPIs delivered as NMI Jacob Pan
2024-06-28 20:18 ` [PATCH v3 10/11] x86/irq: Move __prepare_ICR to x86 common header Jacob Pan
2024-06-28 20:18 ` [PATCH v3 11/11] KVM: X86: Use common code for PV IPIs in linux guest Jacob Pan
2024-06-29 18:38 ` Xin Li
2024-07-01 16:38 ` Jacob Pan
2024-07-01 17:13 ` Xin Li
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=20240628201839.673086-6-jacob.jun.pan@linux.intel.com \
--to=jacob.jun.pan@linux.intel.com \
--cc=acme@kernel.org \
--cc=andi.kleen@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=hpa@zytor.com \
--cc=kan.liang@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=seanjc@google.com \
--cc=sohil.mehta@intel.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
--cc=xin3.li@intel.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;
as well as URLs for NNTP newsgroup(s).