All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ashok Raj <ashok.raj@intel.com>
To: Borislav Petkov <bp@alien8.de>, Thomas Gleixner <tglx@linutronix.de>
Cc: "LKML Mailing List" <linux-kernel@vger.kernel.org>,
	X86-kernel <x86@kernel.org>, Tony Luck <tony.luck@intel.com>,
	Dave Hansen <dave.hansen@intel.com>,
	Arjan van de Ven <arjan.van.de.ven@intel.com>,
	Andy Lutomirski <luto@kernel.org>,
	Jacon Jun Pan <jacob.jun.pan@intel.com>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	Kai Huang <kai.huang@intel.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Jacob Pan <jacob.jun.pan@linux.intel.com>,
	Ashok Raj <ashok.raj@intel.com>
Subject: [v2 06/13] x86/ipi: Support sending NMI_VECTOR as self ipi
Date: Thu,  3 Nov 2022 17:58:54 +0000	[thread overview]
Message-ID: <20221103175901.164783-7-ashok.raj@intel.com> (raw)
In-Reply-To: <20221103175901.164783-1-ashok.raj@intel.com>

From: Jacob Pan <jacob.jun.pan@linux.intel.com>

apic->send_IPI_self() can be used to send any general vector as a self IPI.
The function uses a SHORTCUT specifier, but it can't be used to send a
vector with delivery mode as NMI. Chapter 10, Advanved Programmable
Interrupt Controller (APIC) Table 10-3 indicates that the shortcut isn't a
legal combination for NMI delivery. The same is true for x2apic
implementations as well, the self IPI MSR can only specify the vector
number, but no delivery mode.

The helper adds proper handling if the vector is NMI_VECTOR.

Suggested-by: Ashok Raj <ashok.raj@intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Co-developed-by: Ashok Raj <ashok.raj@intel.com>
Reviewed-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Ashok Raj <ashok.raj@intel.com>
---
 arch/x86/kernel/apic/ipi.c         |  6 +++++-
 arch/x86/kernel/apic/x2apic_phys.c |  6 +++++-
 arch/x86/kernel/nmi_selftest.c     | 32 ++++++++++++++++++++++++++++++
 3 files changed, 42 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/apic/ipi.c b/arch/x86/kernel/apic/ipi.c
index 2a6509e8c840..e967c49609ef 100644
--- a/arch/x86/kernel/apic/ipi.c
+++ b/arch/x86/kernel/apic/ipi.c
@@ -239,7 +239,11 @@ void default_send_IPI_all(int vector)
 
 void default_send_IPI_self(int vector)
 {
-	__default_send_IPI_shortcut(APIC_DEST_SELF, vector);
+	if (unlikely(vector == NMI_VECTOR))
+		apic->send_IPI_mask(cpumask_of(smp_processor_id()),
+				    NMI_VECTOR);
+	else
+		__default_send_IPI_shortcut(APIC_DEST_SELF, vector);
 }
 
 #ifdef CONFIG_X86_32
diff --git a/arch/x86/kernel/apic/x2apic_phys.c b/arch/x86/kernel/apic/x2apic_phys.c
index 6bde05a86b4e..cf187f1906b2 100644
--- a/arch/x86/kernel/apic/x2apic_phys.c
+++ b/arch/x86/kernel/apic/x2apic_phys.c
@@ -149,7 +149,11 @@ int x2apic_phys_pkg_id(int initial_apicid, int index_msb)
 
 void x2apic_send_IPI_self(int vector)
 {
-	apic_write(APIC_SELF_IPI, vector);
+	if (unlikely(vector == NMI_VECTOR))
+		apic->send_IPI_mask(cpumask_of(smp_processor_id()),
+				    NMI_VECTOR);
+	else
+		apic_write(APIC_SELF_IPI, vector);
 }
 
 static struct apic apic_x2apic_phys __ro_after_init = {
diff --git a/arch/x86/kernel/nmi_selftest.c b/arch/x86/kernel/nmi_selftest.c
index a1a96df3dff1..f4b813821208 100644
--- a/arch/x86/kernel/nmi_selftest.c
+++ b/arch/x86/kernel/nmi_selftest.c
@@ -105,6 +105,36 @@ static void __init local_ipi(void)
 	test_nmi_ipi(to_cpumask(nmi_ipi_mask));
 }
 
+static void __init self_nmi_test(void)
+{
+	unsigned long timeout;
+
+	cpumask_clear(to_cpumask(nmi_ipi_mask));
+	cpumask_set_cpu(smp_processor_id(), to_cpumask(nmi_ipi_mask));
+
+	if (register_nmi_handler(NMI_LOCAL, test_nmi_ipi_callback,
+				 NMI_FLAG_FIRST, "nmi_selftest", __initdata)) {
+		nmi_fail = FAILURE;
+		return;
+	}
+
+	/* sync above data before sending NMI */
+	wmb();
+
+	apic->send_IPI_self(NMI_VECTOR);
+
+	/* Don't wait longer than a second */
+	timeout = USEC_PER_SEC;
+	while (!cpumask_empty(to_cpumask(nmi_ipi_mask)) && --timeout)
+		udelay(1);
+
+	/* What happens if we timeout, do we still unregister?? */
+	unregister_nmi_handler(NMI_LOCAL, "nmi_selftest");
+
+	if (!timeout)
+		nmi_fail = TIMEOUT;
+}
+
 static void __init reset_nmi(void)
 {
 	nmi_fail = 0;
@@ -157,6 +187,8 @@ void __init nmi_selftest(void)
 	print_testname("local IPI");
 	dotest(local_ipi, SUCCESS);
 	printk(KERN_CONT "\n");
+	print_testname("Self NMI IPI");
+	dotest(self_nmi_test, SUCCESS);
 
 	cleanup_nmi_testsuite();
 
-- 
2.34.1


  parent reply	other threads:[~2022-11-03 18:00 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-03 17:58 [v2 00/13] Make microcode late loading more robust Ashok Raj
2022-11-03 17:58 ` [v2 01/13] x86/microcode/intel: Prevent printing updated microcode rev multiple times Ashok Raj
2022-11-04 11:00   ` Borislav Petkov
2022-11-04 13:53     ` Van De Ven, Arjan
2022-11-04 15:52       ` Borislav Petkov
2022-11-04 18:28         ` Ashok Raj
2022-11-04 20:21           ` Borislav Petkov
2022-11-06 13:35   ` Borislav Petkov
2022-11-07  4:17     ` Ashok Raj
2022-11-07 16:12     ` Ashok Raj
2022-11-07 18:47       ` Borislav Petkov
2022-11-08 23:06         ` Ashok Raj
2022-11-08 23:32           ` Dave Hansen
2022-11-09  9:18           ` Borislav Petkov
2022-12-03 13:51   ` [tip: x86/microcode] x86/microcode/intel: Do not print microcode revision and processor flags tip-bot2 for Ashok Raj
2022-11-03 17:58 ` [v2 02/13] x86/microcode/intel: Print old and new rev after early microcode update Ashok Raj
2022-11-03 17:58 ` [v2 03/13] x86/microcode/intel: Fix a hang if early loading microcode fails Ashok Raj
2022-11-09 11:25   ` Borislav Petkov
2022-11-09 16:07     ` Ashok Raj
2022-11-09 23:34       ` Borislav Petkov
2022-11-03 17:58 ` [v2 04/13] x86/microcode: Fix microcode_check() compare after a new uCode update Ashok Raj
2022-11-03 17:58 ` [v2 05/13] x86/microcode: Move late-load warning to earlier where kernel taint happens Ashok Raj
2022-11-03 17:58 ` Ashok Raj [this message]
2022-11-03 17:58 ` [v2 07/13] x86/microcode: Place siblings in NMI loop while update in progress Ashok Raj
2022-11-03 17:58 ` [v2 08/13] x86/mce: Warn of a microcode update is in progress when MCE arrives Ashok Raj
2022-11-03 17:58 ` [v2 09/13] x86/microcode/intel: Add minimum required revision to microcode header Ashok Raj
2022-11-03 17:58 ` [v2 10/13] x86/microcode: Add a generic mechanism to declare support for minrev Ashok Raj
2022-11-03 17:58 ` [v2 11/13] x86/microcode/intel: Drop wbinvd() from microcode loading Ashok Raj
2022-11-03 17:59 ` [v2 12/13] x86/microcode: Display revisions only when update is successful Ashok Raj
2022-11-03 17:59 ` [v2 13/13] x86/microcode/intel: Add ability to update microcode even if rev is unchanged Ashok Raj

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=20221103175901.164783-7-ashok.raj@intel.com \
    --to=ashok.raj@intel.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=arjan.van.de.ven@intel.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=jacob.jun.pan@intel.com \
    --cc=jacob.jun.pan@linux.intel.com \
    --cc=kai.huang@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=tony.luck@intel.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.