* [PATCH v1 01/18] arm64/booting: Document boot requirements for FEAT_NMI
2022-11-04 23:54 [PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI Mark Brown
@ 2022-11-04 23:54 ` Mark Brown
2022-11-04 23:54 ` [PATCH v1 02/18] arm64/sysreg: Add definition for ICC_NMIAR1_EL1 Mark Brown
` (17 subsequent siblings)
18 siblings, 0 replies; 27+ messages in thread
From: Mark Brown @ 2022-11-04 23:54 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Marc Zyngier
Cc: Lorenzo Pieralisi, Mark Rutland, Sami Mujawar, Thomas Gleixner,
linux-arm-kernel, 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
^ permalink raw reply related [flat|nested] 27+ messages in thread* [PATCH v1 02/18] arm64/sysreg: Add definition for ICC_NMIAR1_EL1
2022-11-04 23:54 [PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI Mark Brown
2022-11-04 23:54 ` [PATCH v1 01/18] arm64/booting: Document boot requirements " Mark Brown
@ 2022-11-04 23:54 ` Mark Brown
2022-11-04 23:54 ` [PATCH v1 03/18] arm64/sysreg: Add definition of ISR_EL1 Mark Brown
` (16 subsequent siblings)
18 siblings, 0 replies; 27+ messages in thread
From: Mark Brown @ 2022-11-04 23:54 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Marc Zyngier
Cc: Lorenzo Pieralisi, Mark Rutland, Sami Mujawar, Thomas Gleixner,
linux-arm-kernel, 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
^ permalink raw reply related [flat|nested] 27+ messages in thread* [PATCH v1 03/18] arm64/sysreg: Add definition of ISR_EL1
2022-11-04 23:54 [PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI Mark Brown
2022-11-04 23:54 ` [PATCH v1 01/18] arm64/booting: Document boot requirements " Mark Brown
2022-11-04 23:54 ` [PATCH v1 02/18] arm64/sysreg: Add definition for ICC_NMIAR1_EL1 Mark Brown
@ 2022-11-04 23:54 ` Mark Brown
2022-11-04 23:54 ` [PATCH v1 04/18] arm64/sysreg: Add definitions for immediate versions of MSR ALLINT Mark Brown
` (15 subsequent siblings)
18 siblings, 0 replies; 27+ messages in thread
From: Mark Brown @ 2022-11-04 23:54 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Marc Zyngier
Cc: Lorenzo Pieralisi, Mark Rutland, Sami Mujawar, Thomas Gleixner,
linux-arm-kernel, 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
^ permalink raw reply related [flat|nested] 27+ messages in thread* [PATCH v1 04/18] arm64/sysreg: Add definitions for immediate versions of MSR ALLINT
2022-11-04 23:54 [PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI Mark Brown
` (2 preceding siblings ...)
2022-11-04 23:54 ` [PATCH v1 03/18] arm64/sysreg: Add definition of ISR_EL1 Mark Brown
@ 2022-11-04 23:54 ` Mark Brown
2022-11-04 23:54 ` [PATCH v1 05/18] arm64/asm: Introduce assembly macros for managing ALLINT Mark Brown
` (14 subsequent siblings)
18 siblings, 0 replies; 27+ messages in thread
From: Mark Brown @ 2022-11-04 23:54 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Marc Zyngier
Cc: Lorenzo Pieralisi, Mark Rutland, Sami Mujawar, Thomas Gleixner,
linux-arm-kernel, 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
^ permalink raw reply related [flat|nested] 27+ messages in thread* [PATCH v1 05/18] arm64/asm: Introduce assembly macros for managing ALLINT
2022-11-04 23:54 [PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI Mark Brown
` (3 preceding siblings ...)
2022-11-04 23:54 ` [PATCH v1 04/18] arm64/sysreg: Add definitions for immediate versions of MSR ALLINT Mark Brown
@ 2022-11-04 23:54 ` Mark Brown
2022-11-04 23:54 ` [PATCH v1 06/18] arm64/hyp-stub: Enable access to ALLINT Mark Brown
` (13 subsequent siblings)
18 siblings, 0 replies; 27+ messages in thread
From: Mark Brown @ 2022-11-04 23:54 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Marc Zyngier
Cc: Lorenzo Pieralisi, Mark Rutland, Sami Mujawar, Thomas Gleixner,
linux-arm-kernel, 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
^ permalink raw reply related [flat|nested] 27+ messages in thread* [PATCH v1 06/18] arm64/hyp-stub: Enable access to ALLINT
2022-11-04 23:54 [PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI Mark Brown
` (4 preceding siblings ...)
2022-11-04 23:54 ` [PATCH v1 05/18] arm64/asm: Introduce assembly macros for managing ALLINT Mark Brown
@ 2022-11-04 23:54 ` Mark Brown
2022-11-04 23:54 ` [PATCH v1 07/18] arm64/idreg: Add an override for FEAT_NMI Mark Brown
` (12 subsequent siblings)
18 siblings, 0 replies; 27+ messages in thread
From: Mark Brown @ 2022-11-04 23:54 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Marc Zyngier
Cc: Lorenzo Pieralisi, Mark Rutland, Sami Mujawar, Thomas Gleixner,
linux-arm-kernel, 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
^ permalink raw reply related [flat|nested] 27+ messages in thread* [PATCH v1 07/18] arm64/idreg: Add an override for FEAT_NMI
2022-11-04 23:54 [PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI Mark Brown
` (5 preceding siblings ...)
2022-11-04 23:54 ` [PATCH v1 06/18] arm64/hyp-stub: Enable access to ALLINT Mark Brown
@ 2022-11-04 23:54 ` Mark Brown
2022-11-04 23:54 ` [PATCH v1 08/18] arm64/cpufeature: Detect PE support for NMIs Mark Brown
` (11 subsequent siblings)
18 siblings, 0 replies; 27+ messages in thread
From: Mark Brown @ 2022-11-04 23:54 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Marc Zyngier
Cc: Lorenzo Pieralisi, Mark Rutland, Sami Mujawar, Thomas Gleixner,
linux-arm-kernel, 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
^ permalink raw reply related [flat|nested] 27+ messages in thread* [PATCH v1 08/18] arm64/cpufeature: Detect PE support for NMIs
2022-11-04 23:54 [PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI Mark Brown
` (6 preceding siblings ...)
2022-11-04 23:54 ` [PATCH v1 07/18] arm64/idreg: Add an override for FEAT_NMI Mark Brown
@ 2022-11-04 23:54 ` Mark Brown
2022-11-04 23:54 ` [PATCH v1 09/18] arm64/entry: Manage ALLINT.ALLINT when FEAT_NMI is active Mark Brown
` (10 subsequent siblings)
18 siblings, 0 replies; 27+ messages in thread
From: Mark Brown @ 2022-11-04 23:54 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Marc Zyngier
Cc: Lorenzo Pieralisi, Mark Rutland, Sami Mujawar, Thomas Gleixner,
linux-arm-kernel, 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
^ permalink raw reply related [flat|nested] 27+ messages in thread* [PATCH v1 09/18] arm64/entry: Manage ALLINT.ALLINT when FEAT_NMI is active
2022-11-04 23:54 [PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI Mark Brown
` (7 preceding siblings ...)
2022-11-04 23:54 ` [PATCH v1 08/18] arm64/cpufeature: Detect PE support for NMIs Mark Brown
@ 2022-11-04 23:54 ` Mark Brown
2022-11-04 23:54 ` [PATCH v1 10/18] arm64/mm: Disable all interrupts while replacing TTBR1 Mark Brown
` (9 subsequent siblings)
18 siblings, 0 replies; 27+ messages in thread
From: Mark Brown @ 2022-11-04 23:54 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Marc Zyngier
Cc: Lorenzo Pieralisi, Mark Rutland, Sami Mujawar, Thomas Gleixner,
linux-arm-kernel, 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
^ permalink raw reply related [flat|nested] 27+ messages in thread* [PATCH v1 10/18] arm64/mm: Disable all interrupts while replacing TTBR1
2022-11-04 23:54 [PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI Mark Brown
` (8 preceding siblings ...)
2022-11-04 23:54 ` [PATCH v1 09/18] arm64/entry: Manage ALLINT.ALLINT when FEAT_NMI is active Mark Brown
@ 2022-11-04 23:54 ` Mark Brown
2022-11-04 23:54 ` [PATCH v1 11/18] arm64/hibernate: Disable NMIs while hibernating Mark Brown
` (8 subsequent siblings)
18 siblings, 0 replies; 27+ messages in thread
From: Mark Brown @ 2022-11-04 23:54 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Marc Zyngier
Cc: Lorenzo Pieralisi, Mark Rutland, Sami Mujawar, Thomas Gleixner,
linux-arm-kernel, 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
^ permalink raw reply related [flat|nested] 27+ messages in thread* [PATCH v1 11/18] arm64/hibernate: Disable NMIs while hibernating
2022-11-04 23:54 [PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI Mark Brown
` (9 preceding siblings ...)
2022-11-04 23:54 ` [PATCH v1 10/18] arm64/mm: Disable all interrupts while replacing TTBR1 Mark Brown
@ 2022-11-04 23:54 ` Mark Brown
2022-11-04 23:54 ` [PATCH v1 12/18] arm64/suspend: Disable NMIs while suspending Mark Brown
` (7 subsequent siblings)
18 siblings, 0 replies; 27+ messages in thread
From: Mark Brown @ 2022-11-04 23:54 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Marc Zyngier
Cc: Lorenzo Pieralisi, Mark Rutland, Sami Mujawar, Thomas Gleixner,
linux-arm-kernel, 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
^ permalink raw reply related [flat|nested] 27+ messages in thread* [PATCH v1 12/18] arm64/suspend: Disable NMIs while suspending
2022-11-04 23:54 [PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI Mark Brown
` (10 preceding siblings ...)
2022-11-04 23:54 ` [PATCH v1 11/18] arm64/hibernate: Disable NMIs while hibernating Mark Brown
@ 2022-11-04 23:54 ` Mark Brown
2022-11-04 23:54 ` [PATCH v1 13/18] arm64/kexec: Mask NMIs before starting new kernel Mark Brown
` (6 subsequent siblings)
18 siblings, 0 replies; 27+ messages in thread
From: Mark Brown @ 2022-11-04 23:54 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Marc Zyngier
Cc: Lorenzo Pieralisi, Mark Rutland, Sami Mujawar, Thomas Gleixner,
linux-arm-kernel, 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
^ permalink raw reply related [flat|nested] 27+ messages in thread* [PATCH v1 13/18] arm64/kexec: Mask NMIs before starting new kernel
2022-11-04 23:54 [PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI Mark Brown
` (11 preceding siblings ...)
2022-11-04 23:54 ` [PATCH v1 12/18] arm64/suspend: Disable NMIs while suspending Mark Brown
@ 2022-11-04 23:54 ` Mark Brown
2022-11-04 23:54 ` [PATCH v1 14/18] arm64/acpi: Mask NMIs while notifying SEA Mark Brown
` (5 subsequent siblings)
18 siblings, 0 replies; 27+ messages in thread
From: Mark Brown @ 2022-11-04 23:54 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Marc Zyngier
Cc: Lorenzo Pieralisi, Mark Rutland, Sami Mujawar, Thomas Gleixner,
linux-arm-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
^ permalink raw reply related [flat|nested] 27+ messages in thread* [PATCH v1 14/18] arm64/acpi: Mask NMIs while notifying SEA
2022-11-04 23:54 [PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI Mark Brown
` (12 preceding siblings ...)
2022-11-04 23:54 ` [PATCH v1 13/18] arm64/kexec: Mask NMIs before starting new kernel Mark Brown
@ 2022-11-04 23:54 ` Mark Brown
2022-11-04 23:54 ` [PATCH v1 15/18] arm64/irq: Document handling of FEAT_NMI in irqflags.h Mark Brown
` (4 subsequent siblings)
18 siblings, 0 replies; 27+ messages in thread
From: Mark Brown @ 2022-11-04 23:54 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Marc Zyngier
Cc: Lorenzo Pieralisi, Mark Rutland, Sami Mujawar, Thomas Gleixner,
linux-arm-kernel, 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
^ permalink raw reply related [flat|nested] 27+ messages in thread* [PATCH v1 15/18] arm64/irq: Document handling of FEAT_NMI in irqflags.h
2022-11-04 23:54 [PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI Mark Brown
` (13 preceding siblings ...)
2022-11-04 23:54 ` [PATCH v1 14/18] arm64/acpi: Mask NMIs while notifying SEA Mark Brown
@ 2022-11-04 23:54 ` Mark Brown
2022-11-04 23:54 ` [PATCH v1 16/18] arm64/nmi: Add handling of superpriority interrupts as NMIs Mark Brown
` (3 subsequent siblings)
18 siblings, 0 replies; 27+ messages in thread
From: Mark Brown @ 2022-11-04 23:54 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Marc Zyngier
Cc: Lorenzo Pieralisi, Mark Rutland, Sami Mujawar, Thomas Gleixner,
linux-arm-kernel, 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
^ permalink raw reply related [flat|nested] 27+ messages in thread* [PATCH v1 16/18] arm64/nmi: Add handling of superpriority interrupts as NMIs
2022-11-04 23:54 [PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI Mark Brown
` (14 preceding siblings ...)
2022-11-04 23:54 ` [PATCH v1 15/18] arm64/irq: Document handling of FEAT_NMI in irqflags.h Mark Brown
@ 2022-11-04 23:54 ` Mark Brown
2022-11-04 23:54 ` [PATCH v1 17/18] arm64/nmi: Add Kconfig for NMI Mark Brown
` (2 subsequent siblings)
18 siblings, 0 replies; 27+ messages in thread
From: Mark Brown @ 2022-11-04 23:54 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Marc Zyngier
Cc: Lorenzo Pieralisi, Mark Rutland, Sami Mujawar, Thomas Gleixner,
linux-arm-kernel, 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
^ permalink raw reply related [flat|nested] 27+ messages in thread* [PATCH v1 17/18] arm64/nmi: Add Kconfig for NMI
2022-11-04 23:54 [PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI Mark Brown
` (15 preceding siblings ...)
2022-11-04 23:54 ` [PATCH v1 16/18] arm64/nmi: Add handling of superpriority interrupts as NMIs Mark Brown
@ 2022-11-04 23:54 ` Mark Brown
2022-11-04 23:54 ` [PATCH v1 18/18] irqchip/gic-v3: Implement FEAT_GICv3_NMI support Mark Brown
2022-11-06 11:38 ` [PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI Marc Zyngier
18 siblings, 0 replies; 27+ messages in thread
From: Mark Brown @ 2022-11-04 23:54 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Marc Zyngier
Cc: Lorenzo Pieralisi, Mark Rutland, Sami Mujawar, Thomas Gleixner,
linux-arm-kernel, 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
^ permalink raw reply related [flat|nested] 27+ messages in thread* [PATCH v1 18/18] irqchip/gic-v3: Implement FEAT_GICv3_NMI support
2022-11-04 23:54 [PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI Mark Brown
` (16 preceding siblings ...)
2022-11-04 23:54 ` [PATCH v1 17/18] arm64/nmi: Add Kconfig for NMI Mark Brown
@ 2022-11-04 23:54 ` Mark Brown
2022-11-06 11:38 ` [PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI Marc Zyngier
18 siblings, 0 replies; 27+ messages in thread
From: Mark Brown @ 2022-11-04 23:54 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Marc Zyngier
Cc: Lorenzo Pieralisi, Mark Rutland, Sami Mujawar, Thomas Gleixner,
linux-arm-kernel, 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
^ permalink raw reply related [flat|nested] 27+ messages in thread* Re: [PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI
2022-11-04 23:54 [PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI Mark Brown
` (17 preceding siblings ...)
2022-11-04 23:54 ` [PATCH v1 18/18] irqchip/gic-v3: Implement FEAT_GICv3_NMI support Mark Brown
@ 2022-11-06 11:38 ` Marc Zyngier
2022-11-09 15:35 ` Mark Brown
18 siblings, 1 reply; 27+ messages in thread
From: Marc Zyngier @ 2022-11-06 11:38 UTC (permalink / raw)
To: Mark Brown
Cc: Catalin Marinas, Will Deacon, Lorenzo Pieralisi, Mark Rutland,
Sami Mujawar, Thomas Gleixner, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: [PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI
2022-11-06 11:38 ` [PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI Marc Zyngier
@ 2022-11-09 15:35 ` Mark Brown
2022-11-10 8:26 ` Marc Zyngier
2022-12-18 9:40 ` Zenghui Yu
0 siblings, 2 replies; 27+ messages in thread
From: Mark Brown @ 2022-11-09 15:35 UTC (permalink / raw)
To: Marc Zyngier
Cc: Catalin Marinas, Will Deacon, Lorenzo Pieralisi, Mark Rutland,
Sami Mujawar, Thomas Gleixner, linux-arm-kernel
[-- 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
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: [PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI
2022-11-09 15:35 ` Mark Brown
@ 2022-11-10 8:26 ` Marc Zyngier
2022-11-10 11:06 ` Lorenzo Pieralisi
2022-11-10 11:48 ` Mark Brown
2022-12-18 9:40 ` Zenghui Yu
1 sibling, 2 replies; 27+ messages in thread
From: Marc Zyngier @ 2022-11-10 8:26 UTC (permalink / raw)
To: Mark Brown
Cc: Catalin Marinas, Will Deacon, Lorenzo Pieralisi, Mark Rutland,
Sami Mujawar, Thomas Gleixner, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: [PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI
2022-11-10 8:26 ` Marc Zyngier
@ 2022-11-10 11:06 ` Lorenzo Pieralisi
2022-11-14 11:11 ` Marc Zyngier
2022-11-10 11:48 ` Mark Brown
1 sibling, 1 reply; 27+ messages in thread
From: Lorenzo Pieralisi @ 2022-11-10 11:06 UTC (permalink / raw)
To: Marc Zyngier
Cc: Mark Brown, Catalin Marinas, Will Deacon, Mark Rutland,
Sami Mujawar, Thomas Gleixner, linux-arm-kernel
[...]
> > > 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI
2022-11-10 11:06 ` Lorenzo Pieralisi
@ 2022-11-14 11:11 ` Marc Zyngier
0 siblings, 0 replies; 27+ messages in thread
From: Marc Zyngier @ 2022-11-14 11:11 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Mark Brown, Catalin Marinas, Will Deacon, Mark Rutland,
Sami Mujawar, Thomas Gleixner, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI
2022-11-10 8:26 ` Marc Zyngier
2022-11-10 11:06 ` Lorenzo Pieralisi
@ 2022-11-10 11:48 ` Mark Brown
1 sibling, 0 replies; 27+ messages in thread
From: Mark Brown @ 2022-11-10 11:48 UTC (permalink / raw)
To: Marc Zyngier
Cc: Catalin Marinas, Will Deacon, Lorenzo Pieralisi, Mark Rutland,
Sami Mujawar, Thomas Gleixner, linux-arm-kernel
[-- 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI
2022-11-09 15:35 ` Mark Brown
2022-11-10 8:26 ` Marc Zyngier
@ 2022-12-18 9:40 ` Zenghui Yu
2022-12-19 12:36 ` Mark Brown
1 sibling, 1 reply; 27+ messages in thread
From: Zenghui Yu @ 2022-12-18 9:40 UTC (permalink / raw)
To: Mark Brown
Cc: Marc Zyngier, Catalin Marinas, Will Deacon, Lorenzo Pieralisi,
Mark Rutland, Sami Mujawar, Thomas Gleixner, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI
2022-12-18 9:40 ` Zenghui Yu
@ 2022-12-19 12:36 ` Mark Brown
0 siblings, 0 replies; 27+ messages in thread
From: Mark Brown @ 2022-12-19 12:36 UTC (permalink / raw)
To: Zenghui Yu
Cc: Marc Zyngier, Catalin Marinas, Will Deacon, Lorenzo Pieralisi,
Mark Rutland, Sami Mujawar, Thomas Gleixner, linux-arm-kernel
[-- 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
^ permalink raw reply [flat|nested] 27+ messages in thread