* [PATCH 1/6] arm64: Rename the VHE switch to "finalise_el2"
2022-06-27 15:14 [PATCH 0/6] arm64: Disabling SVE/SME from the command-line Marc Zyngier
@ 2022-06-27 15:14 ` Marc Zyngier
2022-06-27 15:14 ` [PATCH 2/6] arm64: Save state of HCR_EL2.E2H before switch to EL1 Marc Zyngier
` (5 subsequent siblings)
6 siblings, 0 replies; 17+ messages in thread
From: Marc Zyngier @ 2022-06-27 15:14 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Will Deacon, Catalin Marinas, Mark Rutland, Ard Biesheuvel,
broonie, danielmentz, saravanak, kernel-team
as we are about to perform a lot more in 'mutate_to_vhe' than
we currently do, this function really becomes the point where
we finalise the basic EL2 configuration.
Reflect this into the code by renaming a bunch of things:
- HVC_VHE_RESTART -> HVC_FINALISE_EL2
- switch_to_vhe --> finalise_el2
- mutate_to_vhe -> __finalise_el2
No functional changes.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
Documentation/virt/kvm/arm/hyp-abi.rst | 2 +-
arch/arm64/include/asm/virt.h | 4 ++--
arch/arm64/kernel/head.S | 6 +++---
arch/arm64/kernel/hyp-stub.S | 21 ++++++++++-----------
arch/arm64/kernel/sleep.S | 2 +-
5 files changed, 17 insertions(+), 18 deletions(-)
diff --git a/Documentation/virt/kvm/arm/hyp-abi.rst b/Documentation/virt/kvm/arm/hyp-abi.rst
index 4d43fbc25195..0967acbff560 100644
--- a/Documentation/virt/kvm/arm/hyp-abi.rst
+++ b/Documentation/virt/kvm/arm/hyp-abi.rst
@@ -60,7 +60,7 @@ these functions (see arch/arm{,64}/include/asm/virt.h):
* ::
- x0 = HVC_VHE_RESTART (arm64 only)
+ x0 = HVC_FINALISE_EL2 (arm64 only)
Attempt to upgrade the kernel's exception level from EL1 to EL2 by enabling
the VHE mode. This is conditioned by the CPU supporting VHE, the EL2 MMU
diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
index 0e80db4327b6..dec6eee0eda5 100644
--- a/arch/arm64/include/asm/virt.h
+++ b/arch/arm64/include/asm/virt.h
@@ -36,9 +36,9 @@
#define HVC_RESET_VECTORS 2
/*
- * HVC_VHE_RESTART - Upgrade the CPU from EL1 to EL2, if possible
+ * HVC_FINALISE_EL2 - Upgrade the CPU from EL1 to EL2, if possible
*/
-#define HVC_VHE_RESTART 3
+#define HVC_FINALISE_EL2 3
/* Max number of HYP stub hypercalls */
#define HVC_STUB_HCALL_NR 4
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 6a98f1a38c29..f8550a939a6e 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -463,7 +463,7 @@ SYM_FUNC_START_LOCAL(__primary_switched)
ret // to __primary_switch()
0:
#endif
- bl switch_to_vhe // Prefer VHE if possible
+ bl finalise_el2 // Prefer VHE if possible
ldp x29, x30, [sp], #16
bl start_kernel
ASM_BUG()
@@ -553,7 +553,7 @@ SYM_INNER_LABEL(init_el2, SYM_L_LOCAL)
eret
__cpu_stick_to_vhe:
- mov x0, #HVC_VHE_RESTART
+ mov x0, #HVC_FINALISE_EL2
hvc #0
mov x0, #BOOT_CPU_MODE_EL2
ret
@@ -634,7 +634,7 @@ SYM_FUNC_START_LOCAL(secondary_startup)
/*
* Common entry point for secondary CPUs.
*/
- bl switch_to_vhe
+ bl finalise_el2
bl __cpu_secondary_check52bitva
bl __cpu_setup // initialise processor
adrp x1, swapper_pg_dir
diff --git a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp-stub.S
index 43d212618834..26206e53e0c9 100644
--- a/arch/arm64/kernel/hyp-stub.S
+++ b/arch/arm64/kernel/hyp-stub.S
@@ -51,8 +51,8 @@ SYM_CODE_START_LOCAL(elx_sync)
msr vbar_el2, x1
b 9f
-1: cmp x0, #HVC_VHE_RESTART
- b.eq mutate_to_vhe
+1: cmp x0, #HVC_FINALISE_EL2
+ b.eq __finalise_el2
2: cmp x0, #HVC_SOFT_RESTART
b.ne 3f
@@ -73,8 +73,8 @@ SYM_CODE_START_LOCAL(elx_sync)
eret
SYM_CODE_END(elx_sync)
-// nVHE? No way! Give me the real thing!
-SYM_CODE_START_LOCAL(mutate_to_vhe)
+SYM_CODE_START_LOCAL(__finalise_el2)
+ // nVHE? No way! Give me the real thing!
// Sanity check: MMU *must* be off
mrs x1, sctlr_el2
tbnz x1, #0, 1f
@@ -140,10 +140,10 @@ SYM_CODE_START_LOCAL(mutate_to_vhe)
msr spsr_el1, x0
b enter_vhe
-SYM_CODE_END(mutate_to_vhe)
+SYM_CODE_END(__finalise_el2)
// At the point where we reach enter_vhe(), we run with
- // the MMU off (which is enforced by mutate_to_vhe()).
+ // the MMU off (which is enforced by __finalise_el2()).
// We thus need to be in the idmap, or everything will
// explode when enabling the MMU.
@@ -222,9 +222,9 @@ SYM_FUNC_START(__hyp_reset_vectors)
SYM_FUNC_END(__hyp_reset_vectors)
/*
- * Entry point to switch to VHE if deemed capable
+ * Entry point to finalise EL2 and switch to VHE if deemed capable
*/
-SYM_FUNC_START(switch_to_vhe)
+SYM_FUNC_START(finalise_el2)
// Need to have booted at EL2
adr_l x1, __boot_cpu_mode
ldr w0, [x1]
@@ -236,9 +236,8 @@ SYM_FUNC_START(switch_to_vhe)
cmp x0, #CurrentEL_EL1
b.ne 1f
- // Turn the world upside down
- mov x0, #HVC_VHE_RESTART
+ mov x0, #HVC_FINALISE_EL2
hvc #0
1:
ret
-SYM_FUNC_END(switch_to_vhe)
+SYM_FUNC_END(finalise_el2)
diff --git a/arch/arm64/kernel/sleep.S b/arch/arm64/kernel/sleep.S
index 4ea9392f86e0..c7e01ee0bda8 100644
--- a/arch/arm64/kernel/sleep.S
+++ b/arch/arm64/kernel/sleep.S
@@ -100,7 +100,7 @@ SYM_FUNC_END(__cpu_suspend_enter)
.pushsection ".idmap.text", "awx"
SYM_CODE_START(cpu_resume)
bl init_kernel_el
- bl switch_to_vhe
+ bl finalise_el2
bl __cpu_setup
/* enable the MMU early - so we can access sleep_save_stash by va */
adrp x1, swapper_pg_dir
--
2.34.1
_______________________________________________
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] 17+ messages in thread* [PATCH 2/6] arm64: Save state of HCR_EL2.E2H before switch to EL1
2022-06-27 15:14 [PATCH 0/6] arm64: Disabling SVE/SME from the command-line Marc Zyngier
2022-06-27 15:14 ` [PATCH 1/6] arm64: Rename the VHE switch to "finalise_el2" Marc Zyngier
@ 2022-06-27 15:14 ` Marc Zyngier
2022-06-27 15:14 ` [PATCH 3/6] arm64: Allow sticky E2H when entering EL1 Marc Zyngier
` (4 subsequent siblings)
6 siblings, 0 replies; 17+ messages in thread
From: Marc Zyngier @ 2022-06-27 15:14 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Will Deacon, Catalin Marinas, Mark Rutland, Ard Biesheuvel,
broonie, danielmentz, saravanak, kernel-team
As we're about to switch the way E2H-stuck CPUs boot, save
the boot CPU E2H state into a global variable that can then be
checked by the iderg override code.
This allows us to replace the is_kernel_in_hyp_mode() check
with a simple comparison with this variable, even when running
at EL1. Note that the variable's validity is pretty short
(it cannot be trusted once a secondary has booted).
Use with caution.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kernel/head.S | 11 +++++++++++
arch/arm64/kernel/idreg-override.c | 10 +++++-----
2 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index f8550a939a6e..d35287c22d30 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -527,6 +527,8 @@ SYM_INNER_LABEL(init_el2, SYM_L_LOCAL)
*/
mrs x0, hcr_el2
and x0, x0, #HCR_E2H
+ adr_l x1, __e2h_state
+ str x0, [x1]
cbz x0, 1f
/* Switching to VHE requires a sane SCTLR_EL1 as a start */
@@ -599,6 +601,15 @@ SYM_DATA_END(__boot_cpu_mode)
SYM_DATA_START(__early_cpu_boot_status)
.quad 0
SYM_DATA_END(__early_cpu_boot_status)
+/*
+ * The value of the boot CPU's HCR_EL2.E2H state before dropping to
+ * EL1, so that the idreg override code can work out whether it can
+ * run in nVHE mode. Note that this is meaningless once a secondary
+ * CPU has booted, as it will have been overwritten.
+ */
+SYM_DATA_START(__e2h_state)
+ .quad 0
+SYM_DATA_END(__e2h_state)
.popsection
diff --git a/arch/arm64/kernel/idreg-override.c b/arch/arm64/kernel/idreg-override.c
index 8a2ceb591686..6abff337b23b 100644
--- a/arch/arm64/kernel/idreg-override.c
+++ b/arch/arm64/kernel/idreg-override.c
@@ -31,13 +31,13 @@ struct ftr_set_desc {
static bool __init mmfr1_vh_filter(u64 val)
{
+ extern u64 __e2h_state;
/*
- * If we ever reach this point while running VHE, we're
- * guaranteed to be on one of these funky, VHE-stuck CPUs. If
- * the user was trying to force nVHE on us, proceed with
- * attitude adjustment.
+ * If the boot CPU has HCR_EL2.E2H set, we're guaranteed to be
+ * on one of these funky, VHE-stuck CPUs. If the user was
+ * trying to force nVHE on us, proceed with attitude adjustment.
*/
- return !(is_kernel_in_hyp_mode() && val == 0);
+ return !(__e2h_state != 0 && val == 0);
}
static const struct ftr_set_desc mmfr1 __initconst = {
--
2.34.1
_______________________________________________
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] 17+ messages in thread* [PATCH 3/6] arm64: Allow sticky E2H when entering EL1
2022-06-27 15:14 [PATCH 0/6] arm64: Disabling SVE/SME from the command-line Marc Zyngier
2022-06-27 15:14 ` [PATCH 1/6] arm64: Rename the VHE switch to "finalise_el2" Marc Zyngier
2022-06-27 15:14 ` [PATCH 2/6] arm64: Save state of HCR_EL2.E2H before switch to EL1 Marc Zyngier
@ 2022-06-27 15:14 ` Marc Zyngier
2022-06-27 15:14 ` [PATCH 4/6] arm64: Factor out checking of a feature against the override into a macro Marc Zyngier
` (3 subsequent siblings)
6 siblings, 0 replies; 17+ messages in thread
From: Marc Zyngier @ 2022-06-27 15:14 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Will Deacon, Catalin Marinas, Mark Rutland, Ard Biesheuvel,
broonie, danielmentz, saravanak, kernel-team
For CPUs that have the unfortunate mis-feature to be stuck in
VHE mode, we perform a funny dance where we completely shortcut
the normal boot process to enable VHE and run the kernel at EL2,
and only then start booting the kernel.
Not only this is pretty ugly, but it means that the EL2 finalisation
occurs before we have processed the sysreg override.
Instead, start executing the kernel as if it was an EL1 guest and
rely on the normal EL2 finalisation to go back to EL2.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kernel/head.S | 30 +++++++-----------------------
1 file changed, 7 insertions(+), 23 deletions(-)
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index d35287c22d30..c4be34133b9c 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -520,6 +520,8 @@ SYM_INNER_LABEL(init_el2, SYM_L_LOCAL)
msr vbar_el2, x0
isb
+ mov_q x1, INIT_SCTLR_EL1_MMU_OFF
+
/*
* Fruity CPUs seem to have HCR_EL2.E2H set to RES1,
* making it impossible to start in nVHE mode. Is that
@@ -531,34 +533,16 @@ SYM_INNER_LABEL(init_el2, SYM_L_LOCAL)
str x0, [x1]
cbz x0, 1f
- /* Switching to VHE requires a sane SCTLR_EL1 as a start */
- mov_q x0, INIT_SCTLR_EL1_MMU_OFF
- msr_s SYS_SCTLR_EL12, x0
-
- /*
- * Force an eret into a helper "function", and let it return
- * to our original caller... This makes sure that we have
- * initialised the basic PSTATE state.
- */
- mov x0, #INIT_PSTATE_EL2
- msr spsr_el1, x0
- adr x0, __cpu_stick_to_vhe
- msr elr_el1, x0
- eret
+ /* Set a sane SCTLR_EL1, the VHE way */
+ msr_s SYS_SCTLR_EL12, x1
+ b 2f
1:
- mov_q x0, INIT_SCTLR_EL1_MMU_OFF
- msr sctlr_el1, x0
-
+ msr sctlr_el1, x1
+2:
msr elr_el2, lr
mov w0, #BOOT_CPU_MODE_EL2
eret
-
-__cpu_stick_to_vhe:
- mov x0, #HVC_FINALISE_EL2
- hvc #0
- mov x0, #BOOT_CPU_MODE_EL2
- ret
SYM_FUNC_END(init_kernel_el)
/*
--
2.34.1
_______________________________________________
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] 17+ messages in thread* [PATCH 4/6] arm64: Factor out checking of a feature against the override into a macro
2022-06-27 15:14 [PATCH 0/6] arm64: Disabling SVE/SME from the command-line Marc Zyngier
` (2 preceding siblings ...)
2022-06-27 15:14 ` [PATCH 3/6] arm64: Allow sticky E2H when entering EL1 Marc Zyngier
@ 2022-06-27 15:14 ` Marc Zyngier
2022-06-28 11:28 ` Mark Brown
2022-06-27 15:14 ` [PATCH 5/6] arm64: Add the arm64.nosme command line option Marc Zyngier
` (2 subsequent siblings)
6 siblings, 1 reply; 17+ messages in thread
From: Marc Zyngier @ 2022-06-27 15:14 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Will Deacon, Catalin Marinas, Mark Rutland, Ard Biesheuvel,
broonie, danielmentz, saravanak, kernel-team
Checking for a feature being supported from assembly code is
a bit tedious if we need to factor in the idreg override.
Since we already have such code written for forcing nVHE, move
the whole thing into a macro. This heavily relies on the override
structure being called foo_override for foo_el1.
No functional change.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kernel/hyp-stub.S | 32 ++++++++++++++++++--------------
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp-stub.S
index 26206e53e0c9..4a02a73650db 100644
--- a/arch/arm64/kernel/hyp-stub.S
+++ b/arch/arm64/kernel/hyp-stub.S
@@ -16,6 +16,23 @@
#include <asm/ptrace.h>
#include <asm/virt.h>
+.macro check_override idreg, fld, pass, fail
+ mrs x1, \idreg\()_el1
+ ubfx x1, x1, #\fld, #4
+ cbz x1, \fail
+
+ adr_l x1, \idreg\()_override
+ ldr x2, [x1, FTR_OVR_VAL_OFFSET]
+ ldr x1, [x1, FTR_OVR_MASK_OFFSET]
+ ubfx x2, x2, #\fld, #4
+ ubfx x1, x1, #\fld, #4
+ cmp x1, xzr
+ and x2, x2, x1
+ csinv x2, x2, xzr, ne
+ cbnz x2, \pass
+ b \fail
+.endm
+
.text
.pushsection .hyp.text, "ax"
@@ -80,20 +97,7 @@ SYM_CODE_START_LOCAL(__finalise_el2)
tbnz x1, #0, 1f
// Needs to be VHE capable, obviously
- mrs x1, id_aa64mmfr1_el1
- ubfx x1, x1, #ID_AA64MMFR1_VHE_SHIFT, #4
- cbz x1, 1f
-
- // Check whether VHE is disabled from the command line
- adr_l x1, id_aa64mmfr1_override
- ldr x2, [x1, FTR_OVR_VAL_OFFSET]
- ldr x1, [x1, FTR_OVR_MASK_OFFSET]
- ubfx x2, x2, #ID_AA64MMFR1_VHE_SHIFT, #4
- ubfx x1, x1, #ID_AA64MMFR1_VHE_SHIFT, #4
- cmp x1, xzr
- and x2, x2, x1
- csinv x2, x2, xzr, ne
- cbnz x2, 2f
+ check_override id_aa64mmfr1 ID_AA64MMFR1_VHE_SHIFT 2f 1f
1: mov_q x0, HVC_STUB_ERR
eret
--
2.34.1
_______________________________________________
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] 17+ messages in thread* Re: [PATCH 4/6] arm64: Factor out checking of a feature against the override into a macro
2022-06-27 15:14 ` [PATCH 4/6] arm64: Factor out checking of a feature against the override into a macro Marc Zyngier
@ 2022-06-28 11:28 ` Mark Brown
2022-06-29 15:46 ` Marc Zyngier
0 siblings, 1 reply; 17+ messages in thread
From: Mark Brown @ 2022-06-28 11:28 UTC (permalink / raw)
To: Marc Zyngier
Cc: linux-arm-kernel, Will Deacon, Catalin Marinas, Mark Rutland,
Ard Biesheuvel, danielmentz, saravanak, kernel-team
[-- Attachment #1.1: Type: text/plain, Size: 426 bytes --]
On Mon, Jun 27, 2022 at 04:14:10PM +0100, Marc Zyngier wrote:
> Checking for a feature being supported from assembly code is
> a bit tedious if we need to factor in the idreg override.
>
> Since we already have such code written for forcing nVHE, move
> the whole thing into a macro. This heavily relies on the override
> structure being called foo_override for foo_el1.
Reviwed-by: Mark Brown <broonie@kernel.org>
[-- 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] 17+ messages in thread
* Re: [PATCH 4/6] arm64: Factor out checking of a feature against the override into a macro
2022-06-28 11:28 ` Mark Brown
@ 2022-06-29 15:46 ` Marc Zyngier
2022-06-29 16:00 ` Mark Brown
0 siblings, 1 reply; 17+ messages in thread
From: Marc Zyngier @ 2022-06-29 15:46 UTC (permalink / raw)
To: Mark Brown
Cc: linux-arm-kernel, Will Deacon, Catalin Marinas, Mark Rutland,
Ard Biesheuvel, danielmentz, saravanak, kernel-team
On Tue, 28 Jun 2022 12:28:32 +0100,
Mark Brown <broonie@kernel.org> wrote:
>
> On Mon, Jun 27, 2022 at 04:14:10PM +0100, Marc Zyngier wrote:
> > Checking for a feature being supported from assembly code is
> > a bit tedious if we need to factor in the idreg override.
> >
> > Since we already have such code written for forcing nVHE, move
> > the whole thing into a macro. This heavily relies on the override
> > structure being called foo_override for foo_el1.
>
> Reviwed-by: Mark Brown <broonie@kernel.org>
Reviewed?
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] 17+ messages in thread
* Re: [PATCH 4/6] arm64: Factor out checking of a feature against the override into a macro
2022-06-29 15:46 ` Marc Zyngier
@ 2022-06-29 16:00 ` Mark Brown
0 siblings, 0 replies; 17+ messages in thread
From: Mark Brown @ 2022-06-29 16:00 UTC (permalink / raw)
To: Marc Zyngier
Cc: linux-arm-kernel, Will Deacon, Catalin Marinas, Mark Rutland,
Ard Biesheuvel, danielmentz, saravanak, kernel-team
[-- Attachment #1.1: Type: text/plain, Size: 692 bytes --]
On Wed, Jun 29, 2022 at 04:46:55PM +0100, Marc Zyngier wrote:
> On Tue, 28 Jun 2022 12:28:32 +0100,
> Mark Brown <broonie@kernel.org> wrote:
> >
> > On Mon, Jun 27, 2022 at 04:14:10PM +0100, Marc Zyngier wrote:
> > > Checking for a feature being supported from assembly code is
> > > a bit tedious if we need to factor in the idreg override.
> > >
> > > Since we already have such code written for forcing nVHE, move
> > > the whole thing into a macro. This heavily relies on the override
> > > structure being called foo_override for foo_el1.
> >
> > Reviwed-by: Mark Brown <broonie@kernel.org>
>
> Reviewed?
Yes, sorry.
Reviewed-by: Mark Brown <broonie@kernel.org>
[-- 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] 17+ messages in thread
* [PATCH 5/6] arm64: Add the arm64.nosme command line option
2022-06-27 15:14 [PATCH 0/6] arm64: Disabling SVE/SME from the command-line Marc Zyngier
` (3 preceding siblings ...)
2022-06-27 15:14 ` [PATCH 4/6] arm64: Factor out checking of a feature against the override into a macro Marc Zyngier
@ 2022-06-27 15:14 ` Marc Zyngier
2022-06-27 17:04 ` Mark Brown
2022-06-27 15:14 ` [PATCH 6/6] arm64: Add the arm64.nosve " Marc Zyngier
2022-06-27 15:18 ` [PATCH 0/6] arm64: Disabling SVE/SME from the command-line Mark Brown
6 siblings, 1 reply; 17+ messages in thread
From: Marc Zyngier @ 2022-06-27 15:14 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Will Deacon, Catalin Marinas, Mark Rutland, Ard Biesheuvel,
broonie, danielmentz, saravanak, kernel-team
In order to be able to completely disable SME even if the HW
seems to support it (most likely because the FW is broken),
move the SME setup into the EL2 finalisation block, and
use a new idreg override to deal with it.
Note that we also nuke id_aa64smfr0_el1 as a byproduct.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
.../admin-guide/kernel-parameters.txt | 3 ++
arch/arm64/include/asm/cpufeature.h | 1 +
arch/arm64/include/asm/el2_setup.h | 45 -------------------
arch/arm64/kernel/cpufeature.c | 4 +-
arch/arm64/kernel/hyp-stub.S | 41 +++++++++++++++++
arch/arm64/kernel/idreg-override.c | 19 +++++++-
6 files changed, 66 insertions(+), 47 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 2522b11e593f..301d2d0fee80 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -400,6 +400,9 @@
arm64.nomte [ARM64] Unconditionally disable Memory Tagging Extension
support
+ arm64.nosme [ARM64] Unconditionally disable Scalable Matrix
+ Extension support
+
ataflop= [HW,M68k]
atarimouse= [HW,MOUSE] Atari Mouse
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index 14a8f3d93add..5adda12b1946 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -909,6 +909,7 @@ static inline unsigned int get_vmid_bits(u64 mmfr1)
extern struct arm64_ftr_override id_aa64mmfr1_override;
extern struct arm64_ftr_override id_aa64pfr1_override;
+extern struct arm64_ftr_override id_aa64smfr0_override;
extern struct arm64_ftr_override id_aa64isar1_override;
extern struct arm64_ftr_override id_aa64isar2_override;
diff --git a/arch/arm64/include/asm/el2_setup.h b/arch/arm64/include/asm/el2_setup.h
index 34ceff08cac4..18641dce5184 100644
--- a/arch/arm64/include/asm/el2_setup.h
+++ b/arch/arm64/include/asm/el2_setup.h
@@ -143,50 +143,6 @@
.Lskip_sve_\@:
.endm
-/* SME register access and priority mapping */
-.macro __init_el2_nvhe_sme
- mrs x1, id_aa64pfr1_el1
- ubfx x1, x1, #ID_AA64PFR1_SME_SHIFT, #4
- cbz x1, .Lskip_sme_\@
-
- bic x0, x0, #CPTR_EL2_TSM // Also disable SME traps
- msr cptr_el2, x0 // Disable copro. traps to EL2
- isb
-
- mrs x1, sctlr_el2
- orr x1, x1, #SCTLR_ELx_ENTP2 // Disable TPIDR2 traps
- msr sctlr_el2, x1
- isb
-
- mov x1, #0 // SMCR controls
-
- mrs_s x2, SYS_ID_AA64SMFR0_EL1
- ubfx x2, x2, #ID_AA64SMFR0_FA64_SHIFT, #1 // Full FP in SM?
- cbz x2, .Lskip_sme_fa64_\@
-
- orr x1, x1, SMCR_ELx_FA64_MASK
-.Lskip_sme_fa64_\@:
-
- orr x1, x1, #SMCR_ELx_LEN_MASK // Enable full SME vector
- msr_s SYS_SMCR_EL2, x1 // length for EL1.
-
- mrs_s x1, SYS_SMIDR_EL1 // Priority mapping supported?
- ubfx x1, x1, #SMIDR_EL1_SMPS_SHIFT, #1
- cbz x1, .Lskip_sme_\@
-
- msr_s SYS_SMPRIMAP_EL2, xzr // Make all priorities equal
-
- mrs x1, id_aa64mmfr1_el1 // HCRX_EL2 present?
- ubfx x1, x1, #ID_AA64MMFR1_HCX_SHIFT, #4
- cbz x1, .Lskip_sme_\@
-
- mrs_s x1, SYS_HCRX_EL2
- orr x1, x1, #HCRX_EL2_SMPME_MASK // Enable priority mapping
- msr_s SYS_HCRX_EL2, x1
-
-.Lskip_sme_\@:
-.endm
-
/* Disable any fine grained traps */
.macro __init_el2_fgt
mrs x1, id_aa64mmfr0_el1
@@ -251,7 +207,6 @@
__init_el2_nvhe_idregs
__init_el2_nvhe_cptr
__init_el2_nvhe_sve
- __init_el2_nvhe_sme
__init_el2_fgt
__init_el2_nvhe_prepare_eret
.endm
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 8d88433de81d..9a7b16347a3f 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -632,6 +632,7 @@ static const struct arm64_ftr_bits ftr_raz[] = {
struct arm64_ftr_override __ro_after_init id_aa64mmfr1_override;
struct arm64_ftr_override __ro_after_init id_aa64pfr1_override;
+struct arm64_ftr_override __ro_after_init id_aa64smfr0_override;
struct arm64_ftr_override __ro_after_init id_aa64isar1_override;
struct arm64_ftr_override __ro_after_init id_aa64isar2_override;
@@ -672,7 +673,8 @@ static const struct __ftr_reg_entry {
ARM64_FTR_REG_OVERRIDE(SYS_ID_AA64PFR1_EL1, ftr_id_aa64pfr1,
&id_aa64pfr1_override),
ARM64_FTR_REG(SYS_ID_AA64ZFR0_EL1, ftr_id_aa64zfr0),
- ARM64_FTR_REG(SYS_ID_AA64SMFR0_EL1, ftr_id_aa64smfr0),
+ ARM64_FTR_REG_OVERRIDE(SYS_ID_AA64SMFR0_EL1, ftr_id_aa64smfr0,
+ &id_aa64smfr0_override),
/* Op1 = 0, CRn = 0, CRm = 5 */
ARM64_FTR_REG(SYS_ID_AA64DFR0_EL1, ftr_id_aa64dfr0),
diff --git a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp-stub.S
index 4a02a73650db..1b61ad63f6f5 100644
--- a/arch/arm64/kernel/hyp-stub.S
+++ b/arch/arm64/kernel/hyp-stub.S
@@ -91,6 +91,47 @@ SYM_CODE_START_LOCAL(elx_sync)
SYM_CODE_END(elx_sync)
SYM_CODE_START_LOCAL(__finalise_el2)
+ check_override id_aa64pfr1 ID_AA64PFR1_SME_SHIFT .Linit_sme .Lskip_sme
+
+.Linit_sme: /* SME register access and priority mapping */
+ msr cptr_el2, x0 // Disable SME traps
+ bic x0, x0, #CPTR_EL2_TSM
+ msr cptr_el2, x0
+ isb
+
+ mrs x1, sctlr_el2
+ orr x1, x1, #SCTLR_ELx_ENTP2 // Disable TPIDR2 traps
+ msr sctlr_el2, x1
+ isb
+
+ mov x1, #0 // SMCR controls
+
+ mrs_s x2, SYS_ID_AA64SMFR0_EL1
+ ubfx x2, x2, #ID_AA64SMFR0_FA64_SHIFT, #1 // Full FP in SM?
+ cbz x2, .Lskip_sme_fa64
+
+ orr x1, x1, SMCR_ELx_FA64_MASK
+.Lskip_sme_fa64:
+
+ orr x1, x1, #SMCR_ELx_LEN_MASK // Enable full SME vector
+ msr_s SYS_SMCR_EL2, x1 // length for EL1.
+
+ mrs_s x1, SYS_SMIDR_EL1 // Priority mapping supported?
+ ubfx x1, x1, #SMIDR_EL1_SMPS_SHIFT, #1
+ cbz x1, .Lskip_sme
+
+ msr_s SYS_SMPRIMAP_EL2, xzr // Make all priorities equal
+
+ mrs x1, id_aa64mmfr1_el1 // HCRX_EL2 present?
+ ubfx x1, x1, #ID_AA64MMFR1_HCX_SHIFT, #4
+ cbz x1, .Lskip_sme
+
+ mrs_s x1, SYS_HCRX_EL2
+ orr x1, x1, #HCRX_EL2_SMPME_MASK // Enable priority mapping
+ msr_s SYS_HCRX_EL2, x1
+
+.Lskip_sme:
+
// nVHE? No way! Give me the real thing!
// Sanity check: MMU *must* be off
mrs x1, sctlr_el2
diff --git a/arch/arm64/kernel/idreg-override.c b/arch/arm64/kernel/idreg-override.c
index 6abff337b23b..d018df6cebf1 100644
--- a/arch/arm64/kernel/idreg-override.c
+++ b/arch/arm64/kernel/idreg-override.c
@@ -49,12 +49,28 @@ static const struct ftr_set_desc mmfr1 __initconst = {
},
};
+static bool __init pfr1_sme_filter(u64 val)
+{
+ /*
+ * Similarly to SVE, disabling SME also means disabling all
+ * the features that are associated with it. Just set
+ * id_aa64smfr0_el1 to 0 and don't look back.
+ */
+ if (!val) {
+ id_aa64smfr0_override.val = 0;
+ id_aa64smfr0_override.mask = GENMASK(63, 0);
+ }
+
+ return true;
+}
+
static const struct ftr_set_desc pfr1 __initconst = {
.name = "id_aa64pfr1",
.override = &id_aa64pfr1_override,
.fields = {
{ "bt", ID_AA64PFR1_BT_SHIFT },
- { "mte", ID_AA64PFR1_MTE_SHIFT},
+ { "mte", ID_AA64PFR1_MTE_SHIFT },
+ { "sme", ID_AA64PFR1_SME_SHIFT, pfr1_sme_filter },
{}
},
};
@@ -108,6 +124,7 @@ static const struct {
} aliases[] __initconst = {
{ "kvm-arm.mode=nvhe", "id_aa64mmfr1.vh=0" },
{ "kvm-arm.mode=protected", "id_aa64mmfr1.vh=0" },
+ { "arm64.nosme", "id_aa64pfr1.sme=0" },
{ "arm64.nobti", "id_aa64pfr1.bt=0" },
{ "arm64.nopauth",
"id_aa64isar1.gpi=0 id_aa64isar1.gpa=0 "
--
2.34.1
_______________________________________________
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] 17+ messages in thread* Re: [PATCH 5/6] arm64: Add the arm64.nosme command line option
2022-06-27 15:14 ` [PATCH 5/6] arm64: Add the arm64.nosme command line option Marc Zyngier
@ 2022-06-27 17:04 ` Mark Brown
2022-06-27 18:08 ` Marc Zyngier
0 siblings, 1 reply; 17+ messages in thread
From: Mark Brown @ 2022-06-27 17:04 UTC (permalink / raw)
To: Marc Zyngier
Cc: linux-arm-kernel, Will Deacon, Catalin Marinas, Mark Rutland,
Ard Biesheuvel, danielmentz, saravanak, kernel-team
[-- Attachment #1.1: Type: text/plain, Size: 612 bytes --]
On Mon, Jun 27, 2022 at 04:14:11PM +0100, Marc Zyngier wrote:
> +.Linit_sme: /* SME register access and priority mapping */
> + msr cptr_el2, x0 // Disable SME traps
> + bic x0, x0, #CPTR_EL2_TSM
> + msr cptr_el2, x0
Should the first msr there be a mrs? If not it should probably have a
comment explaining what it's doing.
> + mov x1, #0 // SMCR controls
> +
> + mrs_s x2, SYS_ID_AA64SMFR0_EL1
> + ubfx x2, x2, #ID_AA64SMFR0_FA64_SHIFT, #1 // Full FP in SM?
> + cbz x2, .Lskip_sme_fa64
I'm sure any firmware authors who enable SME will remember to also
enable FA64 if it's supported in their hardware!
[-- 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] 17+ messages in thread
* Re: [PATCH 5/6] arm64: Add the arm64.nosme command line option
2022-06-27 17:04 ` Mark Brown
@ 2022-06-27 18:08 ` Marc Zyngier
2022-06-27 18:20 ` Mark Brown
0 siblings, 1 reply; 17+ messages in thread
From: Marc Zyngier @ 2022-06-27 18:08 UTC (permalink / raw)
To: Mark Brown
Cc: linux-arm-kernel, Will Deacon, Catalin Marinas, Mark Rutland,
Ard Biesheuvel, danielmentz, saravanak, kernel-team
On Mon, 27 Jun 2022 18:04:05 +0100,
Mark Brown <broonie@kernel.org> wrote:
>
> [1 <text/plain; us-ascii (7bit)>]
> On Mon, Jun 27, 2022 at 04:14:11PM +0100, Marc Zyngier wrote:
>
> > +.Linit_sme: /* SME register access and priority mapping */
> > + msr cptr_el2, x0 // Disable SME traps
> > + bic x0, x0, #CPTR_EL2_TSM
> > + msr cptr_el2, x0
>
> Should the first msr there be a mrs? If not it should probably have a
> comment explaining what it's doing.
Duh. Copy-paste programming, I'm sure it'll go far. :-/
>
> > + mov x1, #0 // SMCR controls
> > +
> > + mrs_s x2, SYS_ID_AA64SMFR0_EL1
> > + ubfx x2, x2, #ID_AA64SMFR0_FA64_SHIFT, #1 // Full FP in SM?
> > + cbz x2, .Lskip_sme_fa64
>
> I'm sure any firmware authors who enable SME will remember to also
> enable FA64 if it's supported in their hardware!
I could add check the override here too. It is a bit ugly as SMFR0
isn't encoded as 4 bit features, but hey, why not.
Thanks,
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] 17+ messages in thread
* Re: [PATCH 5/6] arm64: Add the arm64.nosme command line option
2022-06-27 18:08 ` Marc Zyngier
@ 2022-06-27 18:20 ` Mark Brown
0 siblings, 0 replies; 17+ messages in thread
From: Mark Brown @ 2022-06-27 18:20 UTC (permalink / raw)
To: Marc Zyngier
Cc: linux-arm-kernel, Will Deacon, Catalin Marinas, Mark Rutland,
Ard Biesheuvel, danielmentz, saravanak, kernel-team
[-- Attachment #1.1: Type: text/plain, Size: 646 bytes --]
On Mon, Jun 27, 2022 at 07:08:42PM +0100, Marc Zyngier wrote:
> Mark Brown <broonie@kernel.org> wrote:
> > On Mon, Jun 27, 2022 at 04:14:11PM +0100, Marc Zyngier wrote:
> > > + mrs_s x2, SYS_ID_AA64SMFR0_EL1
> > > + ubfx x2, x2, #ID_AA64SMFR0_FA64_SHIFT, #1 // Full FP in SM?
> > > + cbz x2, .Lskip_sme_fa64
> > I'm sure any firmware authors who enable SME will remember to also
> > enable FA64 if it's supported in their hardware!
> I could add check the override here too. It is a bit ugly as SMFR0
> isn't encoded as 4 bit features, but hey, why not.
It'd be good for completeness and helping track things down if something
does go wrong.
[-- 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] 17+ messages in thread
* [PATCH 6/6] arm64: Add the arm64.nosve command line option
2022-06-27 15:14 [PATCH 0/6] arm64: Disabling SVE/SME from the command-line Marc Zyngier
` (4 preceding siblings ...)
2022-06-27 15:14 ` [PATCH 5/6] arm64: Add the arm64.nosme command line option Marc Zyngier
@ 2022-06-27 15:14 ` Marc Zyngier
2022-06-27 17:08 ` Mark Brown
2022-06-27 15:18 ` [PATCH 0/6] arm64: Disabling SVE/SME from the command-line Mark Brown
6 siblings, 1 reply; 17+ messages in thread
From: Marc Zyngier @ 2022-06-27 15:14 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Will Deacon, Catalin Marinas, Mark Rutland, Ard Biesheuvel,
broonie, danielmentz, saravanak, kernel-team
In order to be able to completely disable SVE even if the HW
seems to support it (most likely because the FW is broken),
move the SVE setup into the EL2 finalisation block, and
use a new idreg override to deal with it.
Note that we also nuke id_aa64zfr0_el1 as a byproduct, and
that SME also gets disabled, due to the dependency between the
two features.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
.../admin-guide/kernel-parameters.txt | 3 +++
arch/arm64/include/asm/cpufeature.h | 2 ++
arch/arm64/include/asm/el2_setup.h | 15 -----------
arch/arm64/kernel/cpufeature.c | 8 ++++--
arch/arm64/kernel/hyp-stub.S | 11 ++++++++
arch/arm64/kernel/idreg-override.c | 26 +++++++++++++++++++
6 files changed, 48 insertions(+), 17 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 301d2d0fee80..0f1344eb7c2f 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -400,6 +400,9 @@
arm64.nomte [ARM64] Unconditionally disable Memory Tagging Extension
support
+ arm64.nosve [ARM64] Unconditionally disable Scalable Vector
+ Extension support
+
arm64.nosme [ARM64] Unconditionally disable Scalable Matrix
Extension support
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index 5adda12b1946..0fc4f6e068e5 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -908,7 +908,9 @@ static inline unsigned int get_vmid_bits(u64 mmfr1)
}
extern struct arm64_ftr_override id_aa64mmfr1_override;
+extern struct arm64_ftr_override id_aa64pfr0_override;
extern struct arm64_ftr_override id_aa64pfr1_override;
+extern struct arm64_ftr_override id_aa64zfr0_override;
extern struct arm64_ftr_override id_aa64smfr0_override;
extern struct arm64_ftr_override id_aa64isar1_override;
extern struct arm64_ftr_override id_aa64isar2_override;
diff --git a/arch/arm64/include/asm/el2_setup.h b/arch/arm64/include/asm/el2_setup.h
index 18641dce5184..2630faa5bc08 100644
--- a/arch/arm64/include/asm/el2_setup.h
+++ b/arch/arm64/include/asm/el2_setup.h
@@ -129,20 +129,6 @@
msr cptr_el2, x0 // Disable copro. traps to EL2
.endm
-/* SVE register access */
-.macro __init_el2_nvhe_sve
- mrs x1, id_aa64pfr0_el1
- ubfx x1, x1, #ID_AA64PFR0_SVE_SHIFT, #4
- cbz x1, .Lskip_sve_\@
-
- bic x0, x0, #CPTR_EL2_TZ // Also disable SVE traps
- msr cptr_el2, x0 // Disable copro. traps to EL2
- isb
- mov x1, #ZCR_ELx_LEN_MASK // SVE: Enable full vector
- msr_s SYS_ZCR_EL2, x1 // length for EL1.
-.Lskip_sve_\@:
-.endm
-
/* Disable any fine grained traps */
.macro __init_el2_fgt
mrs x1, id_aa64mmfr0_el1
@@ -206,7 +192,6 @@
__init_el2_hstr
__init_el2_nvhe_idregs
__init_el2_nvhe_cptr
- __init_el2_nvhe_sve
__init_el2_fgt
__init_el2_nvhe_prepare_eret
.endm
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 9a7b16347a3f..8752eb90c736 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -631,7 +631,9 @@ static const struct arm64_ftr_bits ftr_raz[] = {
__ARM64_FTR_REG_OVERRIDE(#id, id, table, &no_override)
struct arm64_ftr_override __ro_after_init id_aa64mmfr1_override;
+struct arm64_ftr_override __ro_after_init id_aa64pfr0_override;
struct arm64_ftr_override __ro_after_init id_aa64pfr1_override;
+struct arm64_ftr_override __ro_after_init id_aa64zfr0_override;
struct arm64_ftr_override __ro_after_init id_aa64smfr0_override;
struct arm64_ftr_override __ro_after_init id_aa64isar1_override;
struct arm64_ftr_override __ro_after_init id_aa64isar2_override;
@@ -669,10 +671,12 @@ static const struct __ftr_reg_entry {
ARM64_FTR_REG(SYS_ID_MMFR5_EL1, ftr_id_mmfr5),
/* Op1 = 0, CRn = 0, CRm = 4 */
- ARM64_FTR_REG(SYS_ID_AA64PFR0_EL1, ftr_id_aa64pfr0),
+ ARM64_FTR_REG_OVERRIDE(SYS_ID_AA64PFR0_EL1, ftr_id_aa64pfr0,
+ &id_aa64pfr0_override),
ARM64_FTR_REG_OVERRIDE(SYS_ID_AA64PFR1_EL1, ftr_id_aa64pfr1,
&id_aa64pfr1_override),
- ARM64_FTR_REG(SYS_ID_AA64ZFR0_EL1, ftr_id_aa64zfr0),
+ ARM64_FTR_REG_OVERRIDE(SYS_ID_AA64ZFR0_EL1, ftr_id_aa64zfr0,
+ &id_aa64zfr0_override),
ARM64_FTR_REG_OVERRIDE(SYS_ID_AA64SMFR0_EL1, ftr_id_aa64smfr0,
&id_aa64smfr0_override),
diff --git a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp-stub.S
index 1b61ad63f6f5..796cb0b6862a 100644
--- a/arch/arm64/kernel/hyp-stub.S
+++ b/arch/arm64/kernel/hyp-stub.S
@@ -91,6 +91,17 @@ SYM_CODE_START_LOCAL(elx_sync)
SYM_CODE_END(elx_sync)
SYM_CODE_START_LOCAL(__finalise_el2)
+ check_override id_aa64pfr0 ID_AA64PFR0_SVE_SHIFT .Linit_sve .Lskip_sve
+
+.Linit_sve: /* SVE register access */
+ msr cptr_el2, x0 // Disable SVE traps
+ bic x0, x0, #CPTR_EL2_TZ
+ msr cptr_el2, x0
+ isb
+ mov x1, #ZCR_ELx_LEN_MASK // SVE: Enable full vector
+ msr_s SYS_ZCR_EL2, x1 // length for EL1.
+
+.Lskip_sve:
check_override id_aa64pfr1 ID_AA64PFR1_SME_SHIFT .Linit_sme .Lskip_sme
.Linit_sme: /* SME register access and priority mapping */
diff --git a/arch/arm64/kernel/idreg-override.c b/arch/arm64/kernel/idreg-override.c
index d018df6cebf1..909d195ec9fd 100644
--- a/arch/arm64/kernel/idreg-override.c
+++ b/arch/arm64/kernel/idreg-override.c
@@ -49,6 +49,30 @@ static const struct ftr_set_desc mmfr1 __initconst = {
},
};
+static bool __init pfr0_sve_filter(u64 val)
+{
+ /*
+ * Disabling SVE also means disabling all the features that
+ * are associated with it. The easiest way to do it is just to
+ * override id_aa64zfr0_el1 to be 0.
+ */
+ if (!val) {
+ id_aa64zfr0_override.val = 0;
+ id_aa64zfr0_override.mask = GENMASK(63, 0);
+ }
+
+ return true;
+}
+
+static const struct ftr_set_desc pfr0 __initconst = {
+ .name = "id_aa64pfr0",
+ .override = &id_aa64pfr0_override,
+ .fields = {
+ { "sve", ID_AA64PFR0_SVE_SHIFT, pfr0_sve_filter },
+ {}
+ },
+};
+
static bool __init pfr1_sme_filter(u64 val)
{
/*
@@ -112,6 +136,7 @@ static const struct ftr_set_desc kaslr __initconst = {
static const struct ftr_set_desc * const regs[] __initconst = {
&mmfr1,
+ &pfr0,
&pfr1,
&isar1,
&isar2,
@@ -124,6 +149,7 @@ static const struct {
} aliases[] __initconst = {
{ "kvm-arm.mode=nvhe", "id_aa64mmfr1.vh=0" },
{ "kvm-arm.mode=protected", "id_aa64mmfr1.vh=0" },
+ { "arm64.nosve", "id_aa64pfr0.sve=0 id_aa64pfr1.sme=0" },
{ "arm64.nosme", "id_aa64pfr1.sme=0" },
{ "arm64.nobti", "id_aa64pfr1.bt=0" },
{ "arm64.nopauth",
--
2.34.1
_______________________________________________
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] 17+ messages in thread* Re: [PATCH 6/6] arm64: Add the arm64.nosve command line option
2022-06-27 15:14 ` [PATCH 6/6] arm64: Add the arm64.nosve " Marc Zyngier
@ 2022-06-27 17:08 ` Mark Brown
0 siblings, 0 replies; 17+ messages in thread
From: Mark Brown @ 2022-06-27 17:08 UTC (permalink / raw)
To: Marc Zyngier
Cc: linux-arm-kernel, Will Deacon, Catalin Marinas, Mark Rutland,
Ard Biesheuvel, danielmentz, saravanak, kernel-team
[-- Attachment #1.1: Type: text/plain, Size: 294 bytes --]
On Mon, Jun 27, 2022 at 04:14:12PM +0100, Marc Zyngier wrote:
> +.Linit_sve: /* SVE register access */
> + msr cptr_el2, x0 // Disable SVE traps
> + bic x0, x0, #CPTR_EL2_TZ
> + msr cptr_el2, x0
Same mrs/msr thing as with the SME patch - if the code is correct it
probably needs a comment.
[-- 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] 17+ messages in thread
* Re: [PATCH 0/6] arm64: Disabling SVE/SME from the command-line
2022-06-27 15:14 [PATCH 0/6] arm64: Disabling SVE/SME from the command-line Marc Zyngier
` (5 preceding siblings ...)
2022-06-27 15:14 ` [PATCH 6/6] arm64: Add the arm64.nosve " Marc Zyngier
@ 2022-06-27 15:18 ` Mark Brown
2022-06-27 15:30 ` Marc Zyngier
6 siblings, 1 reply; 17+ messages in thread
From: Mark Brown @ 2022-06-27 15:18 UTC (permalink / raw)
To: Marc Zyngier
Cc: linux-arm-kernel, Will Deacon, Catalin Marinas, Mark Rutland,
Ard Biesheuvel, danielmentz, saravanak, kernel-team
[-- Attachment #1.1: Type: text/plain, Size: 518 bytes --]
On Mon, Jun 27, 2022 at 04:14:06PM +0100, Marc Zyngier wrote:
> The main victim here is SVE, because it seems that people have all
> sort of broken firmware out there, and that a distribution kernel
> cannot boot on that. And since we have a dependency between SVE and
> SME, disabling the former also disables the latter.
Oh dear, I've not seen any reports of this. I'm guessing it's TF-A just
not enabling the requisite traps, coupled with people using prebuilt
kernels that turned off SVE when doing validation?
[-- 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] 17+ messages in thread* Re: [PATCH 0/6] arm64: Disabling SVE/SME from the command-line
2022-06-27 15:18 ` [PATCH 0/6] arm64: Disabling SVE/SME from the command-line Mark Brown
@ 2022-06-27 15:30 ` Marc Zyngier
2022-06-27 16:49 ` Mark Brown
0 siblings, 1 reply; 17+ messages in thread
From: Marc Zyngier @ 2022-06-27 15:30 UTC (permalink / raw)
To: Mark Brown
Cc: linux-arm-kernel, Will Deacon, Catalin Marinas, Mark Rutland,
Ard Biesheuvel, danielmentz, saravanak, kernel-team
On Mon, 27 Jun 2022 16:18:36 +0100,
Mark Brown <broonie@kernel.org> wrote:
>
> On Mon, Jun 27, 2022 at 04:14:06PM +0100, Marc Zyngier wrote:
>
> > The main victim here is SVE, because it seems that people have all
> > sort of broken firmware out there, and that a distribution kernel
> > cannot boot on that. And since we have a dependency between SVE and
> > SME, disabling the former also disables the latter.
>
> Oh dear, I've not seen any reports of this. I'm guessing it's TF-A just
> not enabling the requisite traps, coupled with people using prebuilt
> kernels that turned off SVE when doing validation?
Most probably something along these lines. The case I'm aware of
involves booting a vanilla kernel on a system with a half baked
firmware. I have little sympathy for these systems, but this looks
like a reasonable ask to be able to disable a feature from the command
line in order to pinpoint the issue.
Will someone ship a system with this baked into the command line? I
don't believe it for a second (/me ducks).
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] 17+ messages in thread
* Re: [PATCH 0/6] arm64: Disabling SVE/SME from the command-line
2022-06-27 15:30 ` Marc Zyngier
@ 2022-06-27 16:49 ` Mark Brown
0 siblings, 0 replies; 17+ messages in thread
From: Mark Brown @ 2022-06-27 16:49 UTC (permalink / raw)
To: Marc Zyngier
Cc: linux-arm-kernel, Will Deacon, Catalin Marinas, Mark Rutland,
Ard Biesheuvel, danielmentz, saravanak, kernel-team
[-- Attachment #1.1: Type: text/plain, Size: 1263 bytes --]
On Mon, Jun 27, 2022 at 04:30:36PM +0100, Marc Zyngier wrote:
> Mark Brown <broonie@kernel.org> wrote:
> > Oh dear, I've not seen any reports of this. I'm guessing it's TF-A just
> > not enabling the requisite traps, coupled with people using prebuilt
> > kernels that turned off SVE when doing validation?
> Most probably something along these lines. The case I'm aware of
> involves booting a vanilla kernel on a system with a half baked
> firmware. I have little sympathy for these systems, but this looks
> like a reasonable ask to be able to disable a feature from the command
> line in order to pinpoint the issue.
It does, given the number of features that we've got in the pipeline
that require higher EL enablement I was actually wondering if we might
be better off going further and making this more of a standard idiom for
how we add any feature that requires setup at EL2/3 to be functional so
we don't need to go add overrides separately and most likely get them
backported or whatever. There's the AMU which needs CPTR_EL[23].TAM for
example.
> Will someone ship a system with this baked into the command line? I
> don't believe it for a second (/me ducks).
I simply can't understand what you're saying here, must be something
inconceivable.
[-- 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] 17+ messages in thread