[PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI

[PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI

[Mark Brown]

This series enables the architecture and GIC support for the arm64
FEAT_NMI and FEAT_GICv3_NMI extensions in host kernels.  These introduce
support for a new category of interrupts in the architecture code which
we can use to provide NMI functionality, though the interrupts are in
fact maskable as the name would not imply.  The GIC support was done by
Loreozo Pieralisi.

There are two modes for using this FEAT_NMI, the one we use is the one
where any entry to ELn causes all interrupts including those with
superpriority to be masked by a new mask bit ALLINT.ALLINT on entry to
ELn until the mask is explicitly removed by software.  We do this early
in the C entry code for anything that is not a superpriority interrupt,
those are handled without unmasking.  Independent controls are provided
for this feature at each EL, usage at EL1 should not disrupt EL2 or EL3.

Since we can mask these not quite NMIs a large portion of the series is
concerned with updating places where we really do not want to be taking
interrupts of any kind to add masking for NMIs.  This masking is not
added to our standard interrupt masking operations since that would
result in widespread masking of NMIs which would undermine their value.
Given that there's a large amount of kernel code a good proportion of
which I'm not terribly familar with it is likely that this area of the
series needs attention in review as there may be be be areas that have
been missed or misunderstood.

In order to ensure that we do not have both pseudo NMIs and real NMIs
simultaneously enabled we disable NMIs if pseudo NMI support is enabled
in the kernel and has been requested on the command line, since pseudo
NMIs require explicit enablement it seemed most sensible to trust that
the user preferred them for some reason.

Using this feature in KVM guests will require the implementation of vGIC
support which is not present in this series, and there is also no usage
of the feature at EL2.  While FEAT_NMI does add a new writable register
ALLINT the value is already context switched for EL1 via SPSR_EL2.ALLINT 
and we can't trap read access to the register so we don't manage the
write trap that is available in HCRX_EL2.TALLINT.  Guests can read from
the register anyway and should only be able to affect their own state.

Lorenzo Pieralisi (1):
  irqchip/gic-v3: Implement FEAT_GICv3_NMI support

Mark Brown (17):
  arm64/booting: Document boot requirements for FEAT_NMI
  arm64/sysreg: Add definition for ICC_NMIAR1_EL1
  arm64/sysreg: Add definition of ISR_EL1
  arm64/sysreg: Add definitions for immediate versions of MSR ALLINT
  arm64/asm: Introduce assembly macros for managing ALLINT
  arm64/hyp-stub: Enable access to ALLINT
  arm64/idreg: Add an override for FEAT_NMI
  arm64/cpufeature: Detect PE support for NMIs
  arm64/entry: Manage ALLINT.ALLINT when FEAT_NMI is active
  arm64/mm: Disable all interrupts while replacing TTBR1
  arm64/hibernate: Disable NMIs while hibernating
  arm64/suspend: Disable NMIs while suspending
  arm64/kexec: Mask NMIs before starting new kernel
  arm64/acpi: Mask NMIs while notifying SEA
  arm64/irq: Document handling of FEAT_NMI in irqflags.h
  arm64/nmi: Add handling of superpriority interrupts as NMIs
  arm64/nmi: Add Kconfig for NMI

 Documentation/arm64/booting.rst     |   6 ++
 arch/arm64/Kconfig                  |  17 ++++
 arch/arm64/include/asm/assembler.h  |  16 ++++
 arch/arm64/include/asm/cpufeature.h |   6 ++
 arch/arm64/include/asm/daifflags.h  |   1 +
 arch/arm64/include/asm/irq.h        |   2 +
 arch/arm64/include/asm/irqflags.h   |  10 ++
 arch/arm64/include/asm/nmi.h        |  30 ++++++
 arch/arm64/include/asm/sysreg.h     |   2 +
 arch/arm64/kernel/acpi.c            |   8 +-
 arch/arm64/kernel/cpufeature.c      |  55 ++++++++++-
 arch/arm64/kernel/entry-common.c    |  73 ++++++++++++--
 arch/arm64/kernel/hibernate.c       |  12 +++
 arch/arm64/kernel/hyp-stub.S        |  12 +++
 arch/arm64/kernel/idreg-override.c  |   1 +
 arch/arm64/kernel/irq.c             |  32 +++++++
 arch/arm64/kernel/machine_kexec.c   |   2 +
 arch/arm64/kernel/suspend.c         |  11 +++
 arch/arm64/mm/proc.S                |   2 +
 arch/arm64/tools/cpucaps            |   1 +
 arch/arm64/tools/sysreg             |  15 +++
 drivers/irqchip/irq-gic-v3.c        | 143 +++++++++++++++++++++++-----
 include/linux/irqchip/arm-gic-v3.h  |   4 +
 23 files changed, 428 insertions(+), 33 deletions(-)
 create mode 100644 arch/arm64/include/asm/nmi.h


base-commit: 30a0b95b1335e12efef89dd78518ed3e4a71a763
-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v1 01/18] arm64/booting: Document boot requirements for FEAT_NMI

[Mark Brown]

In order to use FEAT_NMI we must be able to use ALLINT, require that it
behave as though not trapped when it is present.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 Documentation/arm64/booting.rst | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst
index 8aefa1001ae5..77d037bc7bf3 100644
--- a/Documentation/arm64/booting.rst
+++ b/Documentation/arm64/booting.rst
@@ -360,6 +360,12 @@ Before jumping into the kernel, the following conditions must be met:
 
     - HCR_EL2.ATA (bit 56) must be initialised to 0b1.
 
+ For CPUs with Non-maskable Interrupts (FEAT_NMI):
+
+ - If the kernel is entered at EL1 and EL2 is present:
+
+   - HCRX_EL2.TALLINT must be initialised to 0b0.
+
 The requirements described above for CPU mode, caches, MMUs, architected
 timers, coherency and system registers apply to all CPUs.  All CPUs must
 enter the kernel in the same exception level.  Where the values documented
-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v1 02/18] arm64/sysreg: Add definition for ICC_NMIAR1_EL1

[Mark Brown]

FEAT_NMI adds a new interrupt status register for NMIs, ICC_NMIAR1_EL1.
Add the definition for this register as per IHI0069H.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/tools/sysreg | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index 384757a7eda9..5d0d2498c635 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -1078,3 +1078,8 @@ Field	23:16	LD
 Res0	15:8
 Field	7:0	LR
 EndSysreg
+
+Sysreg	ICC_NMIAR1_EL1	3	0	12	9	5
+Res0	63:24
+Field	23:0	INTID
+EndSysreg
-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v1 03/18] arm64/sysreg: Add definition of ISR_EL1

[Mark Brown]

Add a definition of ISR_EL1 as per DDI0487I.a. This register was not
previously defined in sysreg.h, no functional changes.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/tools/sysreg | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index 5d0d2498c635..3660e680b7f5 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -1079,6 +1079,16 @@ Res0	15:8
 Field	7:0	LR
 EndSysreg
 
+Sysreg	ISR_EL1	3	0	12	1	0
+Res0	63:11
+Field	10	IS
+Field	9	FS
+Field	8	A
+Field	7	I
+Field	6	F
+Res0	5:0
+EndSysreg
+
 Sysreg	ICC_NMIAR1_EL1	3	0	12	9	5
 Res0	63:24
 Field	23:0	INTID
-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v1 04/18] arm64/sysreg: Add definitions for immediate versions of MSR ALLINT

[Mark Brown]

Encodings are provided for ALLINT which allow setting of ALLINT.ALLINT
using an immediate rather than requiring that a register be loaded with
the value to write. Since these don't currently fit within the scheme we
have for sysreg generation add manual encodings like we currently do for
other similar registers such as SVCR.

Since it is required that these immediate versions be encoded with xzr
as the source register provide asm wrapper which ensure this is the
case.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/include/asm/daifflags.h |  1 +
 arch/arm64/include/asm/nmi.h       | 18 ++++++++++++++++++
 arch/arm64/include/asm/sysreg.h    |  2 ++
 3 files changed, 21 insertions(+)
 create mode 100644 arch/arm64/include/asm/nmi.h

diff --git a/arch/arm64/include/asm/daifflags.h b/arch/arm64/include/asm/daifflags.h
index 55f57dfa8e2f..b3bed2004342 100644
--- a/arch/arm64/include/asm/daifflags.h
+++ b/arch/arm64/include/asm/daifflags.h
@@ -141,4 +141,5 @@ static inline void local_daif_inherit(struct pt_regs *regs)
 	 */
 	write_sysreg(flags, daif);
 }
+
 #endif
diff --git a/arch/arm64/include/asm/nmi.h b/arch/arm64/include/asm/nmi.h
new file mode 100644
index 000000000000..067e2554e144
--- /dev/null
+++ b/arch/arm64/include/asm/nmi.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2022 ARM Ltd.
+ */
+#ifndef __ASM_NMI_H
+#define __ASM_NMI_H
+
+static __always_inline void _allint_clear(void)
+{
+	asm volatile(__msr_s(SYS_ALLINT_CLR, "xzr"));
+}
+
+static __always_inline void _allint_set(void)
+{
+	asm volatile(__msr_s(SYS_ALLINT_SET, "xzr"));
+}
+
+#endif
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 7d301700d1a9..0c07b740c750 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -126,6 +126,8 @@
  * System registers, organised loosely by encoding but grouped together
  * where the architected name contains an index. e.g. ID_MMFR<n>_EL1.
  */
+#define SYS_ALLINT_CLR			sys_reg(0, 1, 4, 0, 0)
+#define SYS_ALLINT_SET			sys_reg(0, 1, 4, 1, 0)
 #define SYS_SVCR_SMSTOP_SM_EL0		sys_reg(0, 3, 4, 2, 3)
 #define SYS_SVCR_SMSTART_SM_EL0		sys_reg(0, 3, 4, 3, 3)
 #define SYS_SVCR_SMSTOP_SMZA_EL0	sys_reg(0, 3, 4, 6, 3)
-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v1 05/18] arm64/asm: Introduce assembly macros for managing ALLINT

[Mark Brown]

In order to allow assembly code to ensure that not even superpriorty
interrupts can preempt it provide macros for enabling and disabling
ALLINT.ALLINT.  This is not integrated into the existing DAIF macros
since we do not always wish to manage ALLINT along with DAIF and the
use of DAIF in the naming of the existing macros might lead to surprises
if ALLINT is also managed.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/include/asm/assembler.h | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
index e5957a53be39..800f9f3926ad 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -90,6 +90,22 @@
 9990:
 	.endm
 
+	.macro	disable_allint
+#ifdef CONFIG_ARM64_NMI
+alternative_if ARM64_HAS_NMI
+	msr_s	SYS_ALLINT_SET, xzr
+alternative_else_nop_endif
+#endif
+	.endm
+
+	.macro	enable_allint
+#ifdef CONFIG_ARM64_NMI
+alternative_if ARM64_HAS_NMI
+	msr_s	SYS_ALLINT_CLR, xzr
+alternative_else_nop_endif
+#endif
+	.endm
+
 /*
  * RAS Error Synchronization barrier
  */
-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v1 06/18] arm64/hyp-stub: Enable access to ALLINT

[Mark Brown]

In order to use NMIs we need to ensure that traps are disabled for it so
update HCRX_EL2 to ensure that TALLINT is not set when we detect support
for NMIs.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/kernel/hyp-stub.S | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp-stub.S
index 2ee18c860f2a..4e0b06467973 100644
--- a/arch/arm64/kernel/hyp-stub.S
+++ b/arch/arm64/kernel/hyp-stub.S
@@ -151,6 +151,18 @@ SYM_CODE_START_LOCAL(__finalise_el2)
 
 .Lskip_sme:
 
+	// NMIs
+	__check_override id_aa64pfr1 ID_AA64PFR1_EL1_NMI_SHIFT 4 .Linit_nmi .Lskip_nmi
+.Linit_nmi:
+	mrs	x1, id_aa64mmfr1_el1		// HCRX_EL2 present?
+	ubfx	x1, x1, #ID_AA64MMFR1_EL1_HCX_SHIFT, #4
+	cbz	x1, .Lskip_nmi
+
+	mrs_s	x1, SYS_HCRX_EL2
+	and	x1, x1, #~HCRX_EL2_TALLINT_MASK	// Don't trap ALLINT
+	msr_s	SYS_HCRX_EL2, x1
+.Lskip_nmi:
+
 	// nVHE? No way! Give me the real thing!
 	// Sanity check: MMU *must* be off
 	mrs	x1, sctlr_el2
-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v1 07/18] arm64/idreg: Add an override for FEAT_NMI

[Mark Brown]

Add a named override for FEAT_NMI, allowing it to be explicitly disabled
in case of problems.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/kernel/idreg-override.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/kernel/idreg-override.c b/arch/arm64/kernel/idreg-override.c
index 95133765ed29..bb25aa3a414b 100644
--- a/arch/arm64/kernel/idreg-override.c
+++ b/arch/arm64/kernel/idreg-override.c
@@ -100,6 +100,7 @@ static const struct ftr_set_desc pfr1 __initconst = {
 	.fields		= {
 		FIELD("bt", ID_AA64PFR1_EL1_BT_SHIFT, NULL ),
 		FIELD("mte", ID_AA64PFR1_EL1_MTE_SHIFT, NULL),
+		FIELD("nmi", ID_AA64PFR1_EL1_NMI_SHIFT, NULL),
 		FIELD("sme", ID_AA64PFR1_EL1_SME_SHIFT, pfr1_sme_filter),
 		{}
 	},
-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v1 08/18] arm64/cpufeature: Detect PE support for NMIs

[Mark Brown]

Use of NMIs requires that all the PEs in the system and the GIC have NMI
support. This patch implements the PE part of that detection and adds
wrapped mask/unmask functions with feature detection in them.

In order to avoid problematic interactions between real and pseudo NMIs
we disable the architected NMIs if the user has enabled pseudo NMIs on
the command line. If this is done on a system where support for the
architected NMIs is detected then a warning is printed during boot in
order to help users spot what is likely to be a misconfiguration.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/include/asm/cpufeature.h |  6 ++++
 arch/arm64/include/asm/nmi.h        | 12 +++++++
 arch/arm64/kernel/cpufeature.c      | 55 ++++++++++++++++++++++++++++-
 arch/arm64/tools/cpucaps            |  1 +
 4 files changed, 73 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index f73f11b55042..85eeb331a0ef 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -809,6 +809,12 @@ static __always_inline bool system_uses_irq_prio_masking(void)
 	       cpus_have_const_cap(ARM64_HAS_IRQ_PRIO_MASKING);
 }
 
+static __always_inline bool system_uses_nmi(void)
+{
+	return IS_ENABLED(CONFIG_ARM64_NMI) &&
+		cpus_have_const_cap(ARM64_HAS_NMI);
+}
+
 static inline bool system_supports_mte(void)
 {
 	return IS_ENABLED(CONFIG_ARM64_MTE) &&
diff --git a/arch/arm64/include/asm/nmi.h b/arch/arm64/include/asm/nmi.h
index 067e2554e144..408af57e23dc 100644
--- a/arch/arm64/include/asm/nmi.h
+++ b/arch/arm64/include/asm/nmi.h
@@ -10,9 +10,21 @@ static __always_inline void _allint_clear(void)
 	asm volatile(__msr_s(SYS_ALLINT_CLR, "xzr"));
 }
 
+static __always_inline void nmi_unmask(void)
+{
+	if (system_uses_nmi())
+		_allint_clear();
+}
+
 static __always_inline void _allint_set(void)
 {
 	asm volatile(__msr_s(SYS_ALLINT_SET, "xzr"));
 }
 
+static __always_inline void nmi_mask(void)
+{
+	if (system_uses_nmi())
+		_allint_set();
+}
+
 #endif
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 6062454a9067..18ab50b76f50 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -84,6 +84,7 @@
 #include <asm/kvm_host.h>
 #include <asm/mmu_context.h>
 #include <asm/mte.h>
+#include <asm/nmi.h>
 #include <asm/processor.h>
 #include <asm/smp.h>
 #include <asm/sysreg.h>
@@ -243,6 +244,7 @@ static const struct arm64_ftr_bits ftr_id_aa64pfr0[] = {
 };
 
 static const struct arm64_ftr_bits ftr_id_aa64pfr1[] = {
+	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR1_EL1_NMI_SHIFT, 4, 0),
 	ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_SME),
 		       FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR1_EL1_SME_SHIFT, 4, 0),
 	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR1_EL1_MPAM_frac_SHIFT, 4, 0),
@@ -2008,9 +2010,11 @@ static void cpu_enable_e0pd(struct arm64_cpu_capabilities const *cap)
 }
 #endif /* CONFIG_ARM64_E0PD */
 
-#ifdef CONFIG_ARM64_PSEUDO_NMI
+#if IS_ENABLED(CONFIG_ARM64_PSEUDO_NMI) || IS_ENABLED(CONFIG_ARM64_NMI)
 static bool enable_pseudo_nmi;
+#endif
 
+#ifdef CONFIG_ARM64_PSEUDO_NMI
 static int __init early_enable_pseudo_nmi(char *p)
 {
 	return strtobool(p, &enable_pseudo_nmi);
@@ -2024,6 +2028,41 @@ static bool can_use_gic_priorities(const struct arm64_cpu_capabilities *entry,
 }
 #endif
 
+#ifdef CONFIG_ARM64_NMI
+static bool has_nmi(const struct arm64_cpu_capabilities *entry, int scope)
+{
+	if (!has_cpuid_feature(entry, scope))
+		return false;
+
+	/*
+	 * Having both real and pseudo NMIs enabled simultaneously is
+	 * likely to cause confusion.  Since pseudo NMIs must be
+	 * enabled with an explicit command line option, if the user
+	 * has set that option on a system with real NMIs for some
+	 * reason assume they know what they're doing.
+	 */
+	if (IS_ENABLED(CONFIG_ARM64_PSEUDO_NMI) && enable_pseudo_nmi) {
+		pr_info("Pseudo NMI enabled, not using architected NMI\n");
+		return false;
+	}
+
+	return true;
+}
+
+static void nmi_enable(const struct arm64_cpu_capabilities *__unused)
+{
+	/*
+	 * Enable use of NMIs controlled by ALLINT, SPINTMASK should
+	 * be clear by default but make it explicit that we are using
+	 * this mode.  Ensure that ALLINT is clear first in order to
+	 * avoid leaving things masked.
+	 */
+	_allint_clear();
+	sysreg_clear_set(sctlr_el1, SCTLR_EL1_SPINTMASK, SCTLR_EL1_NMI);
+	isb();
+}
+#endif
+
 #ifdef CONFIG_ARM64_BTI
 static void bti_enable(const struct arm64_cpu_capabilities *__unused)
 {
@@ -2640,6 +2679,20 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
 		.matches = has_cpuid_feature,
 		.cpu_enable = cpu_trap_el0_impdef,
 	},
+#ifdef CONFIG_ARM64_NMI
+	{
+		.desc = "Non-maskable Interrupts",
+		.capability = ARM64_HAS_NMI,
+		.type = ARM64_CPUCAP_BOOT_CPU_FEATURE,
+		.sys_reg = SYS_ID_AA64PFR1_EL1,
+		.sign = FTR_UNSIGNED,
+		.field_pos = ID_AA64PFR1_EL1_NMI_SHIFT,
+		.field_width = 4,
+		.min_field_value = ID_AA64PFR1_EL1_NMI_IMP,
+		.matches = has_nmi,
+		.cpu_enable = nmi_enable,
+	},
+#endif
 	{},
 };
 
diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
index f1c0347ec31a..fff7517ea590 100644
--- a/arch/arm64/tools/cpucaps
+++ b/arch/arm64/tools/cpucaps
@@ -30,6 +30,7 @@ HAS_GENERIC_AUTH_IMP_DEF
 HAS_IRQ_PRIO_MASKING
 HAS_LDAPR
 HAS_LSE_ATOMICS
+HAS_NMI
 HAS_NO_FPSIMD
 HAS_NO_HW_PREFETCH
 HAS_PAN
-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v1 09/18] arm64/entry: Manage ALLINT.ALLINT when FEAT_NMI is active

[Mark Brown]

As might not be expected given the name the superpriority interrupts
provided by FEAT_NMI can in fact be masked which must be managed by EL1
code to ensure that the time spent with superpriority interrupts masked
is minimised without causing reentrancy issues.

We configure FEAT_NMI with SCTLR_EL1.SPINTMASK clear since we do not use
PSTATE.SP to manage a kernel stack pointer. This means that on entry to
EL1 ALLINT.ALLINT will be set and it is the responsibility of EL1 to clear
it to ensure that both normal and superpriority interrupts are not masked.
Add appropriate code in each EL1 entry path, with no special handling for
superpriority interrupts introduced yet.

Since we need to handle unmasking differently in the case of superpriority
interrupts this code is not factored out into the assembly code. Due to
the number of special cases in the various entry paths and in order to
ensure that superpriority interrupts are masked for as little time as
possible explicit handling in each of the entry points seemed the simplest
and most robust approach.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/kernel/entry-common.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
index 9173fad279af..32547723fcc8 100644
--- a/arch/arm64/kernel/entry-common.c
+++ b/arch/arm64/kernel/entry-common.c
@@ -21,6 +21,7 @@
 #include <asm/irq_regs.h>
 #include <asm/kprobes.h>
 #include <asm/mmu.h>
+#include <asm/nmi.h>
 #include <asm/processor.h>
 #include <asm/sdei.h>
 #include <asm/stacktrace.h>
@@ -294,6 +295,8 @@ static void noinstr __panic_unhandled(struct pt_regs *regs, const char *vector,
 
 	__show_regs(regs);
 	panic("Unhandled exception");
+
+	nmi_unmask();
 }
 
 #define UNHANDLED(el, regsize, vector)							\
@@ -420,6 +423,8 @@ asmlinkage void noinstr el1h_64_sync_handler(struct pt_regs *regs)
 {
 	unsigned long esr = read_sysreg(esr_el1);
 
+	nmi_unmask();
+
 	switch (ESR_ELx_EC(esr)) {
 	case ESR_ELx_EC_DABT_CUR:
 	case ESR_ELx_EC_IABT_CUR:
@@ -477,6 +482,7 @@ static __always_inline void __el1_irq(struct pt_regs *regs,
 static void noinstr el1_interrupt(struct pt_regs *regs,
 				  void (*handler)(struct pt_regs *))
 {
+	nmi_unmask();
 	write_sysreg(DAIF_PROCCTX_NOIRQ, daif);
 
 	if (IS_ENABLED(CONFIG_ARM64_PSEUDO_NMI) && !interrupts_enabled(regs))
@@ -499,6 +505,7 @@ asmlinkage void noinstr el1h_64_error_handler(struct pt_regs *regs)
 {
 	unsigned long esr = read_sysreg(esr_el1);
 
+	nmi_unmask();
 	local_daif_restore(DAIF_ERRCTX);
 	arm64_enter_nmi(regs);
 	do_serror(regs, esr);
@@ -649,6 +656,8 @@ asmlinkage void noinstr el0t_64_sync_handler(struct pt_regs *regs)
 {
 	unsigned long esr = read_sysreg(esr_el1);
 
+	nmi_unmask();
+
 	switch (ESR_ELx_EC(esr)) {
 	case ESR_ELx_EC_SVC64:
 		el0_svc(regs);
@@ -706,6 +715,7 @@ static void noinstr el0_interrupt(struct pt_regs *regs,
 {
 	enter_from_user_mode(regs);
 
+	nmi_unmask();
 	write_sysreg(DAIF_PROCCTX_NOIRQ, daif);
 
 	if (regs->pc & BIT(55))
@@ -742,6 +752,7 @@ static void noinstr __el0_error_handler_common(struct pt_regs *regs)
 {
 	unsigned long esr = read_sysreg(esr_el1);
 
+	nmi_unmask();
 	enter_from_user_mode(regs);
 	local_daif_restore(DAIF_ERRCTX);
 	arm64_enter_nmi(regs);
@@ -777,6 +788,8 @@ asmlinkage void noinstr el0t_32_sync_handler(struct pt_regs *regs)
 {
 	unsigned long esr = read_sysreg(esr_el1);
 
+	nmi_unmask();
+
 	switch (ESR_ELx_EC(esr)) {
 	case ESR_ELx_EC_SVC32:
 		el0_svc_compat(regs);
-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v1 10/18] arm64/mm: Disable all interrupts while replacing TTBR1

[Mark Brown]

We really don't want any exceptions to be delivered while manipulating
TTBR1 so disable ALLINT as well as DAIF in idmap_cpu_replace_ttbr1(),
preventing delivery of NMIs while the replacement is in progress.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/mm/proc.S | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index b9ecbbae1e1a..6bc90fc85d34 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -190,6 +190,7 @@ SYM_FUNC_END(cpu_do_resume)
  */
 SYM_TYPED_FUNC_START(idmap_cpu_replace_ttbr1)
 	save_and_disable_daif flags=x2
+	disable_allint
 
 	__idmap_cpu_set_reserved_ttbr1 x1, x3
 
@@ -197,6 +198,7 @@ SYM_TYPED_FUNC_START(idmap_cpu_replace_ttbr1)
 	msr	ttbr1_el1, x0
 	isb
 
+	enable_allint
 	restore_daif x2
 
 	ret
-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v1 11/18] arm64/hibernate: Disable NMIs while hibernating

[Mark Brown]

We disable interrupts during the final stages of hibernation to ensure we
preserve a consistent image, ensure that NMIs are also masked. Rather than
masking using ALLINT.ALLINT do this by disabling NMIs in SCTLR so that we
don't need to worry about an additional optionally present register in the
assembly sections of code.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/kernel/hibernate.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/kernel/hibernate.c b/arch/arm64/kernel/hibernate.c
index af5df48ba915..71b8979eb2f2 100644
--- a/arch/arm64/kernel/hibernate.c
+++ b/arch/arm64/kernel/hibernate.c
@@ -26,6 +26,7 @@
 #include <asm/memory.h>
 #include <asm/mmu_context.h>
 #include <asm/mte.h>
+#include <asm/nmi.h>
 #include <asm/sections.h>
 #include <asm/smp.h>
 #include <asm/smp_plat.h>
@@ -338,6 +339,14 @@ int swsusp_arch_suspend(void)
 
 	flags = local_daif_save();
 
+	/*
+	 * Disable NMIs in SCTLR rather than masking ALLINT so we
+	 * don't have to worry about the state of the FEAT_NMI
+	 * specific register in the asm code.
+	 */
+	if (system_uses_nmi())
+		sysreg_clear_set(sctlr_el1, SCTLR_EL1_NMI, 0);
+
 	if (__cpu_suspend_enter(&state)) {
 		/* make the crash dump kernel image visible/saveable */
 		crash_prepare_suspend();
@@ -386,6 +395,9 @@ int swsusp_arch_suspend(void)
 		spectre_v4_enable_mitigation(NULL);
 	}
 
+	if (system_uses_nmi())
+		sysreg_clear_set(sctlr_el1, 0, SCTLR_EL1_NMI);
+
 	local_daif_restore(flags);
 
 	return ret;
-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v1 12/18] arm64/suspend: Disable NMIs while suspending

[Mark Brown]

We disable interrupts during the final stages of suspend to ensure we don't
have any code changing state, ensure that NMIs are also masked. Rather than
masking using ALLINT.ALLINT do this by disabling NMIs in SCTLR so that we
don't need to worry about an additional optionally present register in the
assembly sections of code.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/kernel/suspend.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm64/kernel/suspend.c b/arch/arm64/kernel/suspend.c
index 8b02d310838f..e209ad091648 100644
--- a/arch/arm64/kernel/suspend.c
+++ b/arch/arm64/kernel/suspend.c
@@ -105,6 +105,14 @@ int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
 	 */
 	flags = local_daif_save();
 
+	/*
+	 * Disable NMIs in SCTLR rather than masking ALLINT so we
+	 * don't have to worry about the state of the FEAT_NMI
+	 * specific register in the asm code.
+	 */
+	if (system_uses_nmi())
+		sysreg_clear_set(sctlr_el1, SCTLR_EL1_NMI, 0);
+
 	/*
 	 * Function graph tracer state gets inconsistent when the kernel
 	 * calls functions that never return (aka suspend finishers) hence
@@ -139,6 +147,9 @@ int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
 
 	unpause_graph_tracing();
 
+	if (system_uses_nmi())
+		sysreg_clear_set(sctlr_el1, 0, SCTLR_EL1_NMI);
+
 	/*
 	 * Restore pstate flags. OS lock and mdscr have been already
 	 * restored, so from this point onwards, debugging is fully
-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v1 13/18] arm64/kexec: Mask NMIs before starting new kernel

[Mark Brown]

Before we jump into the new kernel we mask interrupts with DAIF so we don't
attempt to handle anything very early in init, if NMIs are enabled then do
the same for NMIs. The new kernel is responsible for initialising SCTLR to
a value it supports, this will include disabling NMIs if they are not in
use.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/kernel/machine_kexec.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
index ce3d40120f72..6ae2a0b3c1df 100644
--- a/arch/arm64/kernel/machine_kexec.c
+++ b/arch/arm64/kernel/machine_kexec.c
@@ -20,6 +20,7 @@
 #include <asm/memory.h>
 #include <asm/mmu.h>
 #include <asm/mmu_context.h>
+#include <asm/nmi.h>
 #include <asm/page.h>
 #include <asm/sections.h>
 #include <asm/trans_pgd.h>
@@ -190,6 +191,7 @@ void machine_kexec(struct kimage *kimage)
 	pr_info("Bye!\n");
 
 	local_daif_mask();
+	nmi_mask();
 
 	/*
 	 * Both restart and kernel_reloc will shutdown the MMU, disable data
-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v1 14/18] arm64/acpi: Mask NMIs while notifying SEA

[Mark Brown]

Since we report SEA as though it were a NMI mask any actual NMIs that
might be delivered during the region marked as a NMI, avoiding any
potential confusion that might result from trying to nest them. Handling
of SError happens with actual NMIs unmasked so we can unconditionally
mask and unmask them.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/kernel/acpi.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index a5a256e3f9fe..7bcb8de84096 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -31,6 +31,7 @@
 #include <asm/cputype.h>
 #include <asm/cpu_ops.h>
 #include <asm/daifflags.h>
+#include <asm/nmi.h>
 #include <asm/smp_plat.h>
 
 int acpi_noirq = 1;		/* skip ACPI IRQ initialization */
@@ -378,13 +379,16 @@ int apei_claim_sea(struct pt_regs *regs)
 		return_to_irqs_enabled = interrupts_enabled(regs);
 
 	/*
-	 * SEA can interrupt SError, mask it and describe this as an NMI so
-	 * that APEI defers the handling.
+	 * SEA can interrupt SError, mask it and describe this as a NMI so
+	 * that APEI defers the handling.  Since we are describing this as
+	 * a NMI also ensure that any actual NMIs are masked while doing so.
 	 */
+	nmi_mask();
 	local_daif_restore(DAIF_ERRCTX);
 	nmi_enter();
 	err = ghes_notify_sea();
 	nmi_exit();
+	nmi_unmask();
 
 	/*
 	 * APEI NMI-like notifications are deferred to irq_work. Unless
-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v1 15/18] arm64/irq: Document handling of FEAT_NMI in irqflags.h

[Mark Brown]

We have documentation at the top of irqflags.h which explains the DAIF
masking. Since the additional masking with NMIs is related and also
covers the IF in DAIF extend the comment to note what's going on with NMIs
though none of the code in irqflags.h is updated to handle NMIs.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/include/asm/irqflags.h | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/include/asm/irqflags.h b/arch/arm64/include/asm/irqflags.h
index b57b9b1e4344..e3f68db456e3 100644
--- a/arch/arm64/include/asm/irqflags.h
+++ b/arch/arm64/include/asm/irqflags.h
@@ -19,6 +19,16 @@
  * always masked and unmasked together, and have no side effects for other
  * flags. Keeping to this order makes it easier for entry.S to know which
  * exceptions should be unmasked.
+ *
+ * With the addition of the FEAT_NMI extension we gain an additional
+ * class of superpriority IRQ/FIQ which is separately masked with a
+ * choice of modes controlled by SCTLR_ELn.{SPINTMASK,NMI}.  Linux
+ * sets SPINTMASK to 0 and NMI to 1 which results in ALLINT.ALLINT
+ * masking both superpriority interrupts and IRQ/FIQ regardless of the
+ * I and F settings. Since these superpriority interrupts are being
+ * used as NMIs we do not include them in the interrupt masking here,
+ * anything that requires that NMIs be masked needs to explicitly do
+ * so.
  */
 
 /*
-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v1 16/18] arm64/nmi: Add handling of superpriority interrupts as NMIs

[Mark Brown]

Our goal with superpriority interrupts is to use them as NMIs, taking
advantage of the much smaller regions where they are masked to allow
prompt handling of the most time critical interrupts.

When an interrupt configured with superpriority we will enter EL1 as
normal for any interrupt, the presence of a superpriority interrupt is
indicated with a status bit in ISR_EL1. We use this to check for the
presence of a superpriority interrupt before we unmask anything in
elX_interrupt(), reporting without unmasking any interrupts.  If no
superpriority interrupt is present then we unmask superpriority
interrupts and proceed with normal interrupt handling.

Both IRQs and FIQs may be configured with superpriority so we handle
both, passing an additional root handler into the elX_interrupt()
function along with the mask for the bit in ISR_EL1 which indicates the
relevant kind of superpriority interrupt. These root handlers can be
configured by the interrupt controller similarly to the root handlers
for normal interrupts using the newly added set_handle_nmi_irq() and
set_handle_nmi_fiq() functions.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/include/asm/irq.h     |  2 +
 arch/arm64/kernel/entry-common.c | 64 +++++++++++++++++++++++++++-----
 arch/arm64/kernel/irq.c          | 32 ++++++++++++++++
 3 files changed, 88 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/include/asm/irq.h b/arch/arm64/include/asm/irq.h
index fac08e18bcd5..2ab05d899bf6 100644
--- a/arch/arm64/include/asm/irq.h
+++ b/arch/arm64/include/asm/irq.h
@@ -8,6 +8,8 @@
 
 struct pt_regs;
 
+int set_handle_nmi_irq(void (*handle_irq)(struct pt_regs *));
+int set_handle_nmi_fiq(void (*handle_fiq)(struct pt_regs *));
 int set_handle_irq(void (*handle_irq)(struct pt_regs *));
 #define set_handle_irq	set_handle_irq
 int set_handle_fiq(void (*handle_fiq)(struct pt_regs *));
diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
index 32547723fcc8..006ccf2f1def 100644
--- a/arch/arm64/kernel/entry-common.c
+++ b/arch/arm64/kernel/entry-common.c
@@ -279,6 +279,8 @@ static void do_interrupt_handler(struct pt_regs *regs,
 	set_irq_regs(old_regs);
 }
 
+extern void (*handle_arch_nmi_irq)(struct pt_regs *);
+extern void (*handle_arch_nmi_fiq)(struct pt_regs *);
 extern void (*handle_arch_irq)(struct pt_regs *);
 extern void (*handle_arch_fiq)(struct pt_regs *);
 
@@ -458,6 +460,15 @@ asmlinkage void noinstr el1h_64_sync_handler(struct pt_regs *regs)
 	}
 }
 
+static __always_inline void __el1_nmi(struct pt_regs *regs,
+				      void (*handler)(struct pt_regs *))
+{
+	arm64_enter_nmi(regs);
+	do_interrupt_handler(regs, handler);
+	arm64_exit_nmi(regs);
+	_allint_clear();
+}
+
 static __always_inline void __el1_pnmi(struct pt_regs *regs,
 				       void (*handler)(struct pt_regs *))
 {
@@ -479,10 +490,21 @@ static __always_inline void __el1_irq(struct pt_regs *regs,
 
 	exit_to_kernel_mode(regs);
 }
-static void noinstr el1_interrupt(struct pt_regs *regs,
-				  void (*handler)(struct pt_regs *))
+
+static void noinstr el1_interrupt(struct pt_regs *regs, u64 nmi_flag,
+				  void (*handler)(struct pt_regs *),
+				  void (*nmi_handler)(struct pt_regs *))
 {
-	nmi_unmask();
+	if (system_uses_nmi()) {
+		/* Is there a NMI to handle? */
+		if (read_sysreg(isr_el1) & nmi_flag) {
+			__el1_nmi(regs, nmi_handler);
+			return;
+		}
+
+		_allint_clear();
+	}
+
 	write_sysreg(DAIF_PROCCTX_NOIRQ, daif);
 
 	if (IS_ENABLED(CONFIG_ARM64_PSEUDO_NMI) && !interrupts_enabled(regs))
@@ -493,12 +515,12 @@ static void noinstr el1_interrupt(struct pt_regs *regs,
 
 asmlinkage void noinstr el1h_64_irq_handler(struct pt_regs *regs)
 {
-	el1_interrupt(regs, handle_arch_irq);
+	el1_interrupt(regs, ISR_EL1_IS, handle_arch_irq, handle_arch_nmi_irq);
 }
 
 asmlinkage void noinstr el1h_64_fiq_handler(struct pt_regs *regs)
 {
-	el1_interrupt(regs, handle_arch_fiq);
+	el1_interrupt(regs, ISR_EL1_FS, handle_arch_fiq, handle_arch_nmi_fiq);
 }
 
 asmlinkage void noinstr el1h_64_error_handler(struct pt_regs *regs)
@@ -710,12 +732,34 @@ asmlinkage void noinstr el0t_64_sync_handler(struct pt_regs *regs)
 	}
 }
 
-static void noinstr el0_interrupt(struct pt_regs *regs,
-				  void (*handler)(struct pt_regs *))
+static void noinstr el0_interrupt(struct pt_regs *regs, u64 nmi_flag,
+				  void (*handler)(struct pt_regs *),
+				  void (*nmi_handler)(struct pt_regs *))
 {
 	enter_from_user_mode(regs);
 
-	nmi_unmask();
+	if (system_uses_nmi()) {
+		/* Is there a NMI to handle? */
+		if (read_sysreg(isr_el1) & nmi_flag) {
+			/*
+			 * Any system with FEAT_NMI should not be
+			 * affected by Spectre v2 so we don't mitigate
+			 * here.
+			 */
+
+			arm64_enter_nmi(regs);
+			do_interrupt_handler(regs, nmi_handler);
+			arm64_exit_nmi(regs);
+
+			_allint_clear();
+
+			exit_to_user_mode(regs);
+			return;
+		}
+
+		_allint_clear();
+	}
+
 	write_sysreg(DAIF_PROCCTX_NOIRQ, daif);
 
 	if (regs->pc & BIT(55))
@@ -730,7 +774,7 @@ static void noinstr el0_interrupt(struct pt_regs *regs,
 
 static void noinstr __el0_irq_handler_common(struct pt_regs *regs)
 {
-	el0_interrupt(regs, handle_arch_irq);
+	el0_interrupt(regs, ISR_EL1_IS, handle_arch_irq, handle_arch_nmi_irq);
 }
 
 asmlinkage void noinstr el0t_64_irq_handler(struct pt_regs *regs)
@@ -740,7 +784,7 @@ asmlinkage void noinstr el0t_64_irq_handler(struct pt_regs *regs)
 
 static void noinstr __el0_fiq_handler_common(struct pt_regs *regs)
 {
-	el0_interrupt(regs, handle_arch_fiq);
+	el0_interrupt(regs, ISR_EL1_FS, handle_arch_fiq, handle_arch_nmi_fiq);
 }
 
 asmlinkage void noinstr el0t_64_fiq_handler(struct pt_regs *regs)
diff --git a/arch/arm64/kernel/irq.c b/arch/arm64/kernel/irq.c
index 38dbd3828f13..77a1ea90b244 100644
--- a/arch/arm64/kernel/irq.c
+++ b/arch/arm64/kernel/irq.c
@@ -85,6 +85,16 @@ void do_softirq_own_stack(void)
 }
 #endif
 
+static void default_handle_nmi_irq(struct pt_regs *regs)
+{
+	panic("Superpriority IRQ taken without a root NMI IRQ handler\n");
+}
+
+static void default_handle_nmi_fiq(struct pt_regs *regs)
+{
+	panic("Superpriority FIQ taken without a root NMI FIQ handler\n");
+}
+
 static void default_handle_irq(struct pt_regs *regs)
 {
 	panic("IRQ taken without a root IRQ handler\n");
@@ -95,9 +105,31 @@ static void default_handle_fiq(struct pt_regs *regs)
 	panic("FIQ taken without a root FIQ handler\n");
 }
 
+void (*handle_arch_nmi_irq)(struct pt_regs *) __ro_after_init = default_handle_nmi_irq;
+void (*handle_arch_nmi_fiq)(struct pt_regs *) __ro_after_init = default_handle_nmi_fiq;
 void (*handle_arch_irq)(struct pt_regs *) __ro_after_init = default_handle_irq;
 void (*handle_arch_fiq)(struct pt_regs *) __ro_after_init = default_handle_fiq;
 
+int __init set_handle_nmi_irq(void (*handle_nmi_irq)(struct pt_regs *))
+{
+	if (handle_arch_nmi_irq != default_handle_nmi_irq)
+		return -EBUSY;
+
+	handle_arch_nmi_irq = handle_nmi_irq;
+	pr_info("Root superpriority IRQ handler: %ps\n", handle_nmi_irq);
+	return 0;
+}
+
+int __init set_handle_nmi_fiq(void (*handle_nmi_fiq)(struct pt_regs *))
+{
+	if (handle_arch_nmi_fiq != default_handle_nmi_fiq)
+		return -EBUSY;
+
+	handle_arch_nmi_fiq = handle_nmi_fiq;
+	pr_info("Root superpriority FIQ handler: %ps\n", handle_nmi_fiq);
+	return 0;
+}
+
 int __init set_handle_irq(void (*handle_irq)(struct pt_regs *))
 {
 	if (handle_arch_irq != default_handle_irq)
-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v1 17/18] arm64/nmi: Add Kconfig for NMI

[Mark Brown]

Since NMI handling is in some fairly hot paths we provide a Kconfig option
which allows support to be compiled out when not needed.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/Kconfig | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 505c8a1ccbe0..dd987a9a4f81 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -2001,6 +2001,23 @@ config ARM64_EPAN
 	  if the cpu does not implement the feature.
 endmenu # "ARMv8.7 architectural features"
 
+menu "ARMv8.8 architectural features"
+
+config ARM64_NMI
+	bool "Enable support for Non-maskable Interrupts (NMI)"
+	default y
+	help
+	  Non-maskable interrupts are an architecture and GIC feature
+	  which allow the system to configure some interrupts to be
+	  configured to have superpriority, allowing them to be handled
+	  before other interrupts and masked for shorter periods of time.
+
+	  The feature is detected at runtime, and will remain disabled
+	  if the cpu does not implement the feature. It will also be
+	  disabled if pseudo NMIs are enabled at runtime.
+
+endmenu # "ARMv8.8 architectural features"
+
 config ARM64_SVE
 	bool "ARM Scalable Vector Extension support"
 	default y
-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v1 18/18] irqchip/gic-v3: Implement FEAT_GICv3_NMI support

[Mark Brown]

From: Lorenzo Pieralisi <lpieralisi@kernel.org>

The FEAT_GICv3_NMI GIC feature coupled with the CPU FEAT_NMI enables
handling NMI interrupts in HW on aarch64, by adding a superpriority
interrupt to the existing GIC priority scheme.

Implement GIC driver support for the FEAT_GICv3_NMI feature.

Rename gic_supports_nmi() helper function to gic_supports_pseudo_nmis()
to make the pseudo NMIs code path clearer and more explicit.

Check, through the ARM64 capabilitity infrastructure, if support
for FEAT_NMI was detected on the core and the system has not overridden
the detection and forced pseudo-NMIs enablement.

If FEAT_NMI is detected, it was not overridden (check embedded in the
system_uses_nmi() call) and the GIC supports the FEAT_GICv3_NMI feature,
install an NMI handler and initialize NMIs related HW GIC registers.

Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
 drivers/irqchip/irq-gic-v3.c       | 143 ++++++++++++++++++++++++-----
 include/linux/irqchip/arm-gic-v3.h |   4 +
 2 files changed, 125 insertions(+), 22 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 34d58567b78d..dc45e1093e7b 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -54,6 +54,7 @@ struct gic_chip_data {
 	u32			nr_redist_regions;
 	u64			flags;
 	bool			has_rss;
+	bool			has_nmi;
 	unsigned int		ppi_nr;
 	struct partition_desc	**ppi_descs;
 };
@@ -145,6 +146,20 @@ enum gic_intid_range {
 	__INVALID_RANGE__
 };
 
+#ifdef CONFIG_ARM64
+#include <asm/cpufeature.h>
+
+static inline bool has_v3_3_nmi(void)
+{
+	return gic_data.has_nmi && system_uses_nmi();
+}
+#else
+static inline bool has_v3_3_nmi(void)
+{
+	return false;
+}
+#endif
+
 static enum gic_intid_range __get_intid_range(irq_hw_number_t hwirq)
 {
 	switch (hwirq) {
@@ -350,6 +365,42 @@ static int gic_peek_irq(struct irq_data *d, u32 offset)
 	return !!(readl_relaxed(base + offset + (index / 32) * 4) & mask);
 }
 
+static DEFINE_RAW_SPINLOCK(irq_controller_lock);
+
+static void gic_irq_configure_nmi(struct irq_data *d, bool enable)
+{
+	void __iomem *base, *addr;
+	u32 offset, index, mask, val;
+
+	offset = convert_offset_index(d, GICD_INMIR, &index);
+	mask = 1 << (index % 32);
+
+	if (gic_irq_in_rdist(d))
+		base = gic_data_rdist_sgi_base();
+	else
+		base = gic_data.dist_base;
+
+	addr = base + offset + (index / 32) * 4;
+
+	raw_spin_lock(&irq_controller_lock);
+
+	val = readl_relaxed(addr);
+	val = enable ? (val | mask) : (val & ~mask);
+	writel_relaxed(val, addr);
+
+	raw_spin_unlock(&irq_controller_lock);
+}
+
+static void gic_irq_enable_nmi(struct irq_data *d)
+{
+	gic_irq_configure_nmi(d, true);
+}
+
+static void gic_irq_disable_nmi(struct irq_data *d)
+{
+	gic_irq_configure_nmi(d, false);
+}
+
 static void gic_poke_irq(struct irq_data *d, u32 offset)
 {
 	void __iomem *base;
@@ -395,7 +446,7 @@ static void gic_unmask_irq(struct irq_data *d)
 	gic_poke_irq(d, GICD_ISENABLER);
 }
 
-static inline bool gic_supports_nmi(void)
+static inline bool gic_supports_pseudo_nmis(void)
 {
 	return IS_ENABLED(CONFIG_ARM64_PSEUDO_NMI) &&
 	       static_branch_likely(&supports_pseudo_nmis);
@@ -491,7 +542,7 @@ static int gic_irq_nmi_setup(struct irq_data *d)
 {
 	struct irq_desc *desc = irq_to_desc(d->irq);
 
-	if (!gic_supports_nmi())
+	if (!gic_supports_pseudo_nmis() && !has_v3_3_nmi())
 		return -EINVAL;
 
 	if (gic_peek_irq(d, GICD_ISENABLER)) {
@@ -519,7 +570,10 @@ static int gic_irq_nmi_setup(struct irq_data *d)
 		desc->handle_irq = handle_fasteoi_nmi;
 	}
 
-	gic_irq_set_prio(d, GICD_INT_NMI_PRI);
+	if (has_v3_3_nmi())
+		gic_irq_enable_nmi(d);
+	else
+		gic_irq_set_prio(d, GICD_INT_NMI_PRI);
 
 	return 0;
 }
@@ -528,7 +582,7 @@ static void gic_irq_nmi_teardown(struct irq_data *d)
 {
 	struct irq_desc *desc = irq_to_desc(d->irq);
 
-	if (WARN_ON(!gic_supports_nmi()))
+	if (WARN_ON(!gic_supports_pseudo_nmis() && !has_v3_3_nmi()))
 		return;
 
 	if (gic_peek_irq(d, GICD_ISENABLER)) {
@@ -554,7 +608,10 @@ static void gic_irq_nmi_teardown(struct irq_data *d)
 		desc->handle_irq = handle_fasteoi_irq;
 	}
 
-	gic_irq_set_prio(d, GICD_INT_DEF_PRI);
+	if (has_v3_3_nmi())
+		gic_irq_disable_nmi(d);
+	else
+		gic_irq_set_prio(d, GICD_INT_DEF_PRI);
 }
 
 static void gic_eoi_irq(struct irq_data *d)
@@ -674,7 +731,7 @@ static inline void gic_complete_ack(u32 irqnr)
 
 static bool gic_rpr_is_nmi_prio(void)
 {
-	if (!gic_supports_nmi())
+	if (!gic_supports_pseudo_nmis())
 		return false;
 
 	return unlikely(gic_read_rpr() == GICD_INT_RPR_PRI(GICD_INT_NMI_PRI));
@@ -706,7 +763,8 @@ static void __gic_handle_nmi(u32 irqnr, struct pt_regs *regs)
 	gic_complete_ack(irqnr);
 
 	if (generic_handle_domain_nmi(gic_data.domain, irqnr)) {
-		WARN_ONCE(true, "Unexpected pseudo-NMI (irqnr %u)\n", irqnr);
+		WARN_ONCE(true, "Unexpected %sNMI (irqnr %u)\n",
+			  gic_supports_pseudo_nmis() ? "pseudo-" : "", irqnr);
 		gic_deactivate_unhandled(irqnr);
 	}
 }
@@ -782,9 +840,37 @@ static void __gic_handle_irq_from_irqsoff(struct pt_regs *regs)
 	__gic_handle_nmi(irqnr, regs);
 }
 
+#ifdef CONFIG_ARM64
+static inline u64 gic_read_nmiar(void)
+{
+	u64 irqstat;
+
+	irqstat = read_sysreg_s(SYS_ICC_NMIAR1_EL1);
+
+	dsb(sy);
+
+	return irqstat;
+}
+
+static asmlinkage void __exception_irq_entry gic_handle_nmi_irq(struct pt_regs *regs)
+{
+	u32 irqnr = gic_read_nmiar();
+
+	__gic_handle_nmi(irqnr, regs);
+}
+
+static inline void gic_setup_nmi_handler(void)
+{
+	if (has_v3_3_nmi())
+		set_handle_nmi_irq(gic_handle_nmi_irq);
+}
+#else
+static inline void gic_setup_nmi_handler(void) { }
+#endif
+
 static asmlinkage void __exception_irq_entry gic_handle_irq(struct pt_regs *regs)
 {
-	if (unlikely(gic_supports_nmi() && !interrupts_enabled(regs)))
+	if (unlikely(gic_supports_pseudo_nmis() && !interrupts_enabled(regs)))
 		__gic_handle_irq_from_irqsoff(regs);
 	else
 		__gic_handle_irq_from_irqson(regs);
@@ -1072,7 +1158,7 @@ static void gic_cpu_sys_reg_init(void)
 	/* Set priority mask register */
 	if (!gic_prio_masking_enabled()) {
 		write_gicreg(DEFAULT_PMR_VALUE, ICC_PMR_EL1);
-	} else if (gic_supports_nmi()) {
+	} else if (gic_supports_pseudo_nmis()) {
 		/*
 		 * Mismatch configuration with boot CPU, the system is likely
 		 * to die as interrupt masking will not work properly on all
@@ -1753,20 +1839,8 @@ static const struct gic_quirk gic_quirks[] = {
 	}
 };
 
-static void gic_enable_nmi_support(void)
+static void gic_enable_pseudo_nmis(void)
 {
-	int i;
-
-	if (!gic_prio_masking_enabled())
-		return;
-
-	ppi_nmi_refs = kcalloc(gic_data.ppi_nr, sizeof(*ppi_nmi_refs), GFP_KERNEL);
-	if (!ppi_nmi_refs)
-		return;
-
-	for (i = 0; i < gic_data.ppi_nr; i++)
-		refcount_set(&ppi_nmi_refs[i], 0);
-
 	/*
 	 * Linux itself doesn't use 1:N distribution, so has no need to
 	 * set PMHE. The only reason to have it set is if EL3 requires it
@@ -1809,6 +1883,28 @@ static void gic_enable_nmi_support(void)
 		static_branch_enable(&gic_nonsecure_priorities);
 
 	static_branch_enable(&supports_pseudo_nmis);
+}
+
+static void gic_enable_nmi_support(void)
+{
+	int i;
+
+	if (!gic_prio_masking_enabled() && !has_v3_3_nmi())
+		return;
+
+	ppi_nmi_refs = kcalloc(gic_data.ppi_nr, sizeof(*ppi_nmi_refs), GFP_KERNEL);
+	if (!ppi_nmi_refs)
+		return;
+
+	for (i = 0; i < gic_data.ppi_nr; i++)
+		refcount_set(&ppi_nmi_refs[i], 0);
+
+	/*
+	 * Initialize pseudo-NMIs only if GIC driver cannot take advantage
+	 * of core (FEAT_NMI) and GIC (FEAT_GICv3_NMI) in HW
+	 */
+	if (!has_v3_3_nmi())
+		gic_enable_pseudo_nmis();
 
 	if (static_branch_likely(&supports_deactivate_key))
 		gic_eoimode1_chip.flags |= IRQCHIP_SUPPORTS_NMI;
@@ -1872,6 +1968,7 @@ static int __init gic_init_bases(void __iomem *dist_base,
 	irq_domain_update_bus_token(gic_data.domain, DOMAIN_BUS_WIRED);
 
 	gic_data.has_rss = !!(typer & GICD_TYPER_RSS);
+	gic_data.has_nmi = !!(typer & GICD_TYPER_NMI);
 
 	if (typer & GICD_TYPER_MBIS) {
 		err = mbi_init(handle, gic_data.domain);
@@ -1881,6 +1978,8 @@ static int __init gic_init_bases(void __iomem *dist_base,
 
 	set_handle_irq(gic_handle_irq);
 
+	gic_setup_nmi_handler();
+
 	gic_update_rdist_properties();
 
 	gic_dist_init();
diff --git a/include/linux/irqchip/arm-gic-v3.h b/include/linux/irqchip/arm-gic-v3.h
index 728691365464..3306456c135f 100644
--- a/include/linux/irqchip/arm-gic-v3.h
+++ b/include/linux/irqchip/arm-gic-v3.h
@@ -30,6 +30,7 @@
 #define GICD_ICFGR			0x0C00
 #define GICD_IGRPMODR			0x0D00
 #define GICD_NSACR			0x0E00
+#define GICD_INMIR			0x0F80
 #define GICD_IGROUPRnE			0x1000
 #define GICD_ISENABLERnE		0x1200
 #define GICD_ICENABLERnE		0x1400
@@ -39,6 +40,7 @@
 #define GICD_ICACTIVERnE		0x1C00
 #define GICD_IPRIORITYRnE		0x2000
 #define GICD_ICFGRnE			0x3000
+#define GICD_INMIRnE			0x3B00
 #define GICD_IROUTER			0x6000
 #define GICD_IROUTERnE			0x8000
 #define GICD_IDREGS			0xFFD0
@@ -83,6 +85,7 @@
 #define GICD_TYPER_LPIS			(1U << 17)
 #define GICD_TYPER_MBIS			(1U << 16)
 #define GICD_TYPER_ESPI			(1U << 8)
+#define GICD_TYPER_NMI			(1U << 9)
 
 #define GICD_TYPER_ID_BITS(typer)	((((typer) >> 19) & 0x1f) + 1)
 #define GICD_TYPER_NUM_LPIS(typer)	((((typer) >> 11) & 0x1f) + 1)
@@ -238,6 +241,7 @@
 #define GICR_ICFGR0			GICD_ICFGR
 #define GICR_IGRPMODR0			GICD_IGRPMODR
 #define GICR_NSACR			GICD_NSACR
+#define GICR_INMIR0			GICD_INMIR
 
 #define GICR_TYPER_PLPIS		(1U << 0)
 #define GICR_TYPER_VLPIS		(1U << 1)
-- 
2.30.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI

[Marc Zyngier]

On Fri, 04 Nov 2022 23:54:35 +0000,
Mark Brown <broonie@kernel.org> wrote:
> 
> This series enables the architecture and GIC support for the arm64
> FEAT_NMI and FEAT_GICv3_NMI extensions in host kernels.  These introduce
> support for a new category of interrupts in the architecture code which
> we can use to provide NMI functionality, though the interrupts are in
> fact maskable as the name would not imply.  The GIC support was done by
> Loreozo Pieralisi.
> 
> There are two modes for using this FEAT_NMI, the one we use is the one
> where any entry to ELn causes all interrupts including those with
> superpriority to be masked by a new mask bit ALLINT.ALLINT on entry to
> ELn until the mask is explicitly removed by software.  We do this early
> in the C entry code for anything that is not a superpriority interrupt,
> those are handled without unmasking.  Independent controls are provided
> for this feature at each EL, usage at EL1 should not disrupt EL2 or EL3.
> 
> Since we can mask these not quite NMIs a large portion of the series is
> concerned with updating places where we really do not want to be taking
> interrupts of any kind to add masking for NMIs.  This masking is not
> added to our standard interrupt masking operations since that would
> result in widespread masking of NMIs which would undermine their value.
> Given that there's a large amount of kernel code a good proportion of
> which I'm not terribly familar with it is likely that this area of the
> series needs attention in review as there may be be be areas that have
> been missed or misunderstood.

Can you at least clarify why the no-quite-NMI cannot follow the
pattern established by the pseudo-NMI support? I would have expected
the critical sections to strictly map between the two so-called-NMI
implementations.

> 
> In order to ensure that we do not have both pseudo NMIs and real NMIs
> simultaneously enabled we disable NMIs if pseudo NMI support is enabled
> in the kernel and has been requested on the command line, since pseudo
> NMIs require explicit enablement it seemed most sensible to trust that
> the user preferred them for some reason.
> 
> Using this feature in KVM guests will require the implementation of vGIC
> support which is not present in this series, and there is also no usage
> of the feature at EL2.  While FEAT_NMI does add a new writable register
> ALLINT the value is already context switched for EL1 via SPSR_EL2.ALLINT 
> and we can't trap read access to the register so we don't manage the
> write trap that is available in HCRX_EL2.TALLINT.  Guests can read from
> the register anyway and should only be able to affect their own state.

... and create some architectural state that is impossible to manage
and migrate. Great.

Frankly, we are accumulating a bunch of half implemented features
(SME, SPE) for which there is no KVM support, and I don't think this
is the correct direction of travel.

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 4887 bytes --]

On Sun, Nov 06, 2022 at 11:38:51AM +0000, Marc Zyngier wrote:
> Mark Brown <broonie@kernel.org> wrote:

> > interrupts of any kind to add masking for NMIs.  This masking is not
> > added to our standard interrupt masking operations since that would
> > result in widespread masking of NMIs which would undermine their value.
> > Given that there's a large amount of kernel code a good proportion of
> > which I'm not terribly familar with it is likely that this area of the
> > series needs attention in review as there may be be be areas that have
> > been missed or misunderstood.

> Can you at least clarify why the no-quite-NMI cannot follow the
> pattern established by the pseudo-NMI support? I would have expected
> the critical sections to strictly map between the two so-called-NMI
> implementations.

That's fair, I'll expand on this topic in the cover for next version.
It is basically similar, there's a few differences where I couldn't
convince myself that we were intentionally masking NMIs like
el0_svc_common() and it did seem like we wanted to control things
separately during entry given the separate report path we have with the
architected version.  It's possible I've completely misunderstood this
one way or another.

I did look at a couple of alernatives that had more overlap.  I looked
at pulling the pNMI code out of the DAIF handling but given the
implementation the benefits seemed unclear for the complexity given that
it is actually working with DAIF.  I did also strongly consider putting
the NMI handling into the DAIF handling but that was making it difficult
to distinguish the handling of architected NMIs and the implicit
coverage didn't seem ideal, I could have another spin through that
approach though - I was on the edge with the approach there.  It sounds
like you'd really prefer that one.

> > Using this feature in KVM guests will require the implementation of vGIC
> > support which is not present in this series, and there is also no usage
> > of the feature at EL2.  While FEAT_NMI does add a new writable register
> > ALLINT the value is already context switched for EL1 via SPSR_EL2.ALLINT 
> > and we can't trap read access to the register so we don't manage the
> > write trap that is available in HCRX_EL2.TALLINT.  Guests can read from
> > the register anyway and should only be able to affect their own state.

> ... and create some architectural state that is impossible to manage
> and migrate. Great.

We can't already manage and migrate SPSR_EL2 (or SPSR_EL1 for that
matter)?  I might have missed part of how that's handled or used,
especially given that I've not actively worked through this yet, but if
we're not doing so then we've got other problems with for example
PSTATE.BTYPE or PSTATE.SSBS.  It looks like it's available and I'm not
seeing any filtering of the values or anything.

Note that ALLINT.ALLINT is similar to DAIF or SBSS, it's directly
mirroring the state of PSTATE.ALLINT.  The only access EL2 has to the
EL1 state for ALLINT is via SPSR, on entry to EL2 ALLINT is reset as per
the configuration in SCTLR_EL2.{SPINTMASK,NMI} and then the EL1 value is
restored as part of exception return.

> Frankly, we are accumulating a bunch of half implemented features
> (SME, SPE) for which there is no KVM support, and I don't think this
> is the correct direction of travel.

Yeah, it's not great.  For NMIs Lorenzo is looking at the GIC side, I'll
let him clarify his schedule.  Here it's more the case that implementing
the architecture side without an interrupt controller isn't useful (and
certainly not usefully testable) than anything else - my expectation is
that it should work fine, though from your comments above it sounds like
there will be issues with the handling of PSTATE that I've not realised.

For SME you should start seeing at least preparatory bits very soon
after the SME2 support lands, it's pretty much at the top of my list but
it didn't seem great to have yet another large, interdependent series in
flight at once so.  I had initially been hoping to get the KVM support
on the list in the gap between SME being merged and SME2 being public
but what happened instead is that it took so long to get review of SME
(with all the new ABI going on it's not 100% surprising it was slow but
it was much slower than I expected) that it ran into the SME2 release.
SME2 is only adding a single register of architectural state plus
instructions so I'm hoping it will go a bit quicker but OTOH we're
coming up to Christmas.  This backlog is the main reason I'm reluctant
to do any non-essential cleanups with the FP stuff at the minute - it
just increases the number of things that could cause conflicts or
dependency issues and those are likely to loose a release cycle.

I'm not aware of the situation with SPE.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI

[Marc Zyngier]

On Wed, 09 Nov 2022 15:35:25 +0000,
Mark Brown <broonie@kernel.org> wrote:
> 
> [1  <text/plain; us-ascii (quoted-printable)>]
> On Sun, Nov 06, 2022 at 11:38:51AM +0000, Marc Zyngier wrote:
> > Mark Brown <broonie@kernel.org> wrote:
> 
> > > interrupts of any kind to add masking for NMIs.  This masking is not
> > > added to our standard interrupt masking operations since that would
> > > result in widespread masking of NMIs which would undermine their value.
> > > Given that there's a large amount of kernel code a good proportion of
> > > which I'm not terribly familar with it is likely that this area of the
> > > series needs attention in review as there may be be be areas that have
> > > been missed or misunderstood.
> 
> > Can you at least clarify why the no-quite-NMI cannot follow the
> > pattern established by the pseudo-NMI support? I would have expected
> > the critical sections to strictly map between the two so-called-NMI
> > implementations.
> 
> That's fair, I'll expand on this topic in the cover for next version.
> It is basically similar, there's a few differences where I couldn't
> convince myself that we were intentionally masking NMIs like
> el0_svc_common() and it did seem like we wanted to control things
> separately during entry given the separate report path we have with the
> architected version.  It's possible I've completely misunderstood this
> one way or another.
> 
> I did look at a couple of alernatives that had more overlap.  I looked
> at pulling the pNMI code out of the DAIF handling but given the
> implementation the benefits seemed unclear for the complexity given that
> it is actually working with DAIF.  I did also strongly consider putting
> the NMI handling into the DAIF handling but that was making it difficult
> to distinguish the handling of architected NMIs and the implicit
> coverage didn't seem ideal, I could have another spin through that
> approach though - I was on the edge with the approach there.  It sounds
> like you'd really prefer that one.

My gripe with the current approach is that it took us a *very* long
while to make pNMI work correctly in all cases (I'm pretty sure that
Mark Rutland still has nightmares about it). But now that we have the
framework for it and the mental model to match, I'd really want both
NMI methods to be merely two implementations of the same concept.

The only obvious difference should be that we can identify NMIs early
and that acking a NMI cannot result in acking an IRQ. I'd expect
everything else to be otherwise similar.

> 
> > > Using this feature in KVM guests will require the implementation of vGIC
> > > support which is not present in this series, and there is also no usage
> > > of the feature at EL2.  While FEAT_NMI does add a new writable register
> > > ALLINT the value is already context switched for EL1 via SPSR_EL2.ALLINT 
> > > and we can't trap read access to the register so we don't manage the
> > > write trap that is available in HCRX_EL2.TALLINT.  Guests can read from
> > > the register anyway and should only be able to affect their own state.
> 
> > ... and create some architectural state that is impossible to manage
> > and migrate. Great.
> 
> We can't already manage and migrate SPSR_EL2 (or SPSR_EL1 for that
> matter)?

Of course we can. SPSR_EL2 is nothing but the guest's PSTATE, and
thankfully we manage it. Same thing for SPSR_EL1.

> I might have missed part of how that's handled or used,
> especially given that I've not actively worked through this yet, but if
> we're not doing so then we've got other problems with for example
> PSTATE.BTYPE or PSTATE.SSBS.  It looks like it's available and I'm not
> seeing any filtering of the values or anything.

Imagine you run a VM on some FEAT_NMI-enabled HW. The guest uses the
PSTATE.ALLINT bit because it can. Now we migrate the VM somewhere else
that doesn't have ALLINT, and the VM is dead.

This is a general problem with the architecture, but we definitely
should take care of it as we're enabling these features.

> 
> Note that ALLINT.ALLINT is similar to DAIF or SBSS, it's directly
> mirroring the state of PSTATE.ALLINT.  The only access EL2 has to the
> EL1 state for ALLINT is via SPSR, on entry to EL2 ALLINT is reset as per
> the configuration in SCTLR_EL2.{SPINTMASK,NMI} and then the EL1 value is
> restored as part of exception return.
> 
> > Frankly, we are accumulating a bunch of half implemented features
> > (SME, SPE) for which there is no KVM support, and I don't think this
> > is the correct direction of travel.
> 
> Yeah, it's not great.  For NMIs Lorenzo is looking at the GIC side, I'll
> let him clarify his schedule.  Here it's more the case that implementing
> the architecture side without an interrupt controller isn't useful (and
> certainly not usefully testable) than anything else - my expectation is
> that it should work fine, though from your comments above it sounds like
> there will be issues with the handling of PSTATE that I've not realised.

The vgic support should be rather trivial. It is only a matter of
adding the required interrupt state, reworking the priority sorting
and LR stuffing, handling the additional MMIO range and dealing with
the GIC versioning. Trapping of ALLINT should be done at the same
time.

If people cannot be bothered, I'll end-up doing it myself.

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI

[Lorenzo Pieralisi]

[...]

> > > Frankly, we are accumulating a bunch of half implemented features
> > > (SME, SPE) for which there is no KVM support, and I don't think this
> > > is the correct direction of travel.
> > 
> > Yeah, it's not great.  For NMIs Lorenzo is looking at the GIC side, I'll
> > let him clarify his schedule.  Here it's more the case that implementing
> > the architecture side without an interrupt controller isn't useful (and
> > certainly not usefully testable) than anything else - my expectation is
> > that it should work fine, though from your comments above it sounds like
> > there will be issues with the handling of PSTATE that I've not realised.
> 
> The vgic support should be rather trivial. It is only a matter of
> adding the required interrupt state, reworking the priority sorting
> and LR stuffing, handling the additional MMIO range and dealing with
> the GIC versioning. Trapping of ALLINT should be done at the same
> time.
> 
> If people cannot be bothered, I'll end-up doing it myself.

Apologies for the slow feedback.

I should be able to do it - I thought that we could start with sorting out
the host required changes but it makes sense to make the KVM changes at
the same time.

Lorenzo

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 2800 bytes --]

On Thu, Nov 10, 2022 at 08:26:44AM +0000, Marc Zyngier wrote:

> My gripe with the current approach is that it took us a *very* long
> while to make pNMI work correctly in all cases (I'm pretty sure that
> Mark Rutland still has nightmares about it). But now that we have the
> framework for it and the mental model to match, I'd really want both
> NMI methods to be merely two implementations of the same concept.

> The only obvious difference should be that we can identify NMIs early
> and that acking a NMI cannot result in acking an IRQ. I'd expect
> everything else to be otherwise similar.

OK, I can respin easily enough with that approach I think.  We can
try to reduce the locked regions incrementally I guess.  My impression
had been that the issues had been more around managing the GIC.

> > I might have missed part of how that's handled or used,
> > especially given that I've not actively worked through this yet, but if
> > we're not doing so then we've got other problems with for example
> > PSTATE.BTYPE or PSTATE.SSBS.  It looks like it's available and I'm not
> > seeing any filtering of the values or anything.

> Imagine you run a VM on some FEAT_NMI-enabled HW. The guest uses the
> PSTATE.ALLINT bit because it can. Now we migrate the VM somewhere else
> that doesn't have ALLINT, and the VM is dead.

> This is a general problem with the architecture, but we definitely
> should take care of it as we're enabling these features.

Ah, I see - that's a relief.  I wasn't super sympathetic to any guests
that might try to enumerate the feature by checking for an UNDEF on the
register rather than the ID registers, but yes that would allow such
guests to run until migrated rather than dying immediately when they try
to write to the register.  I'd thought you were concerned about an issue
for unmigrated VMs.

> > Yeah, it's not great.  For NMIs Lorenzo is looking at the GIC side, I'll
> > let him clarify his schedule.  Here it's more the case that implementing
> > the architecture side without an interrupt controller isn't useful (and
> > certainly not usefully testable) than anything else - my expectation is
> > that it should work fine, though from your comments above it sounds like
> > there will be issues with the handling of PSTATE that I've not realised.

> The vgic support should be rather trivial. It is only a matter of
> adding the required interrupt state, reworking the priority sorting
> and LR stuffing, handling the additional MMIO range and dealing with
> the GIC versioning. Trapping of ALLINT should be done at the same
> time.

> If people cannot be bothered, I'll end-up doing it myself.

It'll get done, it's more a question of the split of work between myself
and Lorenzo together with starting to push the review for the
architecture side.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI

[Marc Zyngier]

On Thu, 10 Nov 2022 11:06:25 +0000,
Lorenzo Pieralisi <lpieralisi@kernel.org> wrote:
> 
> [...]
> 
> > > > Frankly, we are accumulating a bunch of half implemented features
> > > > (SME, SPE) for which there is no KVM support, and I don't think this
> > > > is the correct direction of travel.
> > > 
> > > Yeah, it's not great.  For NMIs Lorenzo is looking at the GIC side, I'll
> > > let him clarify his schedule.  Here it's more the case that implementing
> > > the architecture side without an interrupt controller isn't useful (and
> > > certainly not usefully testable) than anything else - my expectation is
> > > that it should work fine, though from your comments above it sounds like
> > > there will be issues with the handling of PSTATE that I've not realised.
> > 
> > The vgic support should be rather trivial. It is only a matter of
> > adding the required interrupt state, reworking the priority sorting
> > and LR stuffing, handling the additional MMIO range and dealing with
> > the GIC versioning. Trapping of ALLINT should be done at the same
> > time.
> > 
> > If people cannot be bothered, I'll end-up doing it myself.
> 
> Apologies for the slow feedback.
> 
> I should be able to do it - I thought that we could start with sorting out
> the host required changes but it makes sense to make the KVM changes at
> the same time.

I'm reviving the couple of hacks I had come up with a long while ago,
and will point you to them once I'm done. Feel free to take them or
ignore them altogether.

Cheers,

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI

[Zenghui Yu]

Hi Mark,

On 2022/11/9 23:35, Mark Brown wrote:
> For SME you should start seeing at least preparatory bits very soon
> after the SME2 support lands, it's pretty much at the top of my list but
> it didn't seem great to have yet another large, interdependent series in
> flight at once so.  I had initially been hoping to get the KVM support
> on the list in the gap between SME being merged and SME2 being public
> but what happened instead is that it took so long to get review of SME
> (with all the new ABI going on it's not 100% surprising it was slow but
> it was much slower than I expected) that it ran into the SME2 release.
> SME2 is only adding a single register of architectural state plus
> instructions so I'm hoping it will go a bit quicker but OTOH we're
> coming up to Christmas.  This backlog is the main reason I'm reluctant
> to do any non-essential cleanups with the FP stuff at the minute - it
> just increases the number of things that could cause conflicts or
> dependency issues and those are likely to loose a release cycle.

Out of curiosity, is there any public branch you can share (assuming
that the KVM side prototype of SME support is under development) or are
there already some patches on the list that I hadn't noticed? Having
asked that, I'm pretty happy to be Cc-ed on that once it gets ready so
that I can start testing things on the emulator (or on real HW, if
possible) and participate in the review.

Thanks,
Zenghui

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 887 bytes --]

On Sun, Dec 18, 2022 at 05:40:52PM +0800, Zenghui Yu wrote:
> On 2022/11/9 23:35, Mark Brown wrote:

> > For SME you should start seeing at least preparatory bits very soon
> > after the SME2 support lands, it's pretty much at the top of my list but
> > it didn't seem great to have yet another large, interdependent series in

> Out of curiosity, is there any public branch you can share (assuming
> that the KVM side prototype of SME support is under development) or are
> there already some patches on the list that I hadn't noticed? Having
> asked that, I'm pretty happy to be Cc-ed on that once it gets ready so
> that I can start testing things on the emulator (or on real HW, if
> possible) and participate in the review.

No, there's nothing available yet - I'm waiting for the dependencies to
make some progress to try to keep the amount of pending code I'm
carrying managable.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel