Skip to contentSkip to conversation

arm64: Early CPU feature override, and applications to VHE, BTI and PAuth

PATCH Superseded Marc Zyngier 4 participants 38 messages Jan 25, 2021

Subsystems (4)

v5 of 7 Superseded Latest is v7 →

lore
Share & tools
lore

Marc Zyngier

author maintainer
#0 lore raw

v5 cover arm64: Early CPU feature override, and applications to VHE, BTI and PAuth

It recently came to light that there is a need to be able to override some CPU features very early on, before the kernel is fully up and running. The reasons for this range from specific feature support (such as using Protected KVM on VHE HW, which is the main motivation for this work) to errata workaround (a feature is broken on a CPU and needs to be turned off, or rather not enabled).

This series tries to offer a limited framework for this kind of problems, by allowing a set of options to be passed on the command-line and altering the feature set that the cpufeature subsystem exposes to the rest of the kernel. Note that this doesn't change anything for code that directly uses the CPU ID registers.

The series completely changes the way a VHE-capable system boots, by *always* booting non-VHE first, and then upgrading to VHE when deemed capable. Although it sounds scary, this is actually simple to implement (and I wish I had done that five years ago). The "upgrade to VHE" path is then conditioned on the VHE feature not being disabled from the command-line.

Said command-line parsing borrows a lot from the kaslr code, and subsequently allows the "nokaslr" option to be moved to the new infrastructure (though it all looks a bit... odd).

Further patches now add support for disabling BTI and PAuth, the latter being based on an initial series by Srinivas Ramana[0]. There is some ongoing discussions about being able to disable MTE, but no clear resolution on that subject yet.

This has been tested on multiple VHE and non-VHE systems.

* From v4 [4]:
- Documentation fixes
- Moved the val/mask pair into a arm64_ftr_override structure, leading to simpler code
- All arm64_ftr_reg now have a default override, which simplifies the code a bit further
- Dropped some of the "const" attributes
- Renamed init_shadow_regs() to init_feature_override()
- Renamed struct reg_desc to struct ftr_set_desc
- Refactored command-line parsing
- Simplified handling of VHE being disabled on the cmdline
- Turn EL1 S1 MMU off on switch to VHE
- HVC_VHE_RESTART now returns an error code on failure
- Added missing asmlinkage and dummy prototypes
- Collected Acks and RBs from David, Catalin and Suzuki

* From v3 [3]:
- Fixed the VHE_RESTART stub (duh!)
- Switched to using arm64_ftr_safe_value() instead of the user provided value
- Per-feature override warning

* From v2 [2]:
- Simplify the VHE_RESTART stub
- Fixed a number of spelling mistakes, and hopefully introduced a few more
- Override features in __read_sysreg_by_encoding()
- Allow both BTI and PAuth to be overridden on the command line
- Rebased on -rc3

* From v1 [1]:
- Fix SPE init on VHE when EL2 doesn't own SPE
- Fix re-init when KASLR is used
- Handle the resume path
- Rebased to 5.11-rc2

[0] https://lore.kernel.org/r/[email protected]
[1] https://lore.kernel.org/r/[email protected]
[2] https://lore.kernel.org/r/[email protected]
[3] https://lore.kernel.org/r/[email protected]
[4] https://lore.kernel.org/r/[email protected]

Marc Zyngier (20):
arm64: Fix labels in el2_setup macros
arm64: Fix outdated TCR setup comment
arm64: Turn the MMU-on sequence into a macro
arm64: Provide an 'upgrade to VHE' stub hypercall
arm64: Initialise as nVHE before switching to VHE
arm64: Move VHE-specific SPE setup to mutate_to_vhe()
arm64: Simplify init_el2_state to be non-VHE only
arm64: Move SCTLR_EL1 initialisation to EL-agnostic code
arm64: cpufeature: Add global feature override facility
arm64: cpufeature: Use IDreg override in __read_sysreg_by_encoding()
arm64: Extract early FDT mapping from kaslr_early_init()
arm64: cpufeature: Add an early command-line cpufeature override
facility
arm64: Allow ID_AA64MMFR1_EL1.VH to be overridden from the command
line
arm64: Honor VHE being disabled from the command-line
arm64: Add an aliasing facility for the idreg override
arm64: Make kvm-arm.mode={nvhe, protected} an alias of

    id_aa64mmfr1.vh=0

KVM: arm64: Document HVC_VHE_RESTART stub hypercall
arm64: Move "nokaslr" over to the early cpufeature infrastructure
arm64: cpufeatures: Allow disabling of BTI from the command-line
arm64: cpufeatures: Allow disabling of Pointer Auth from the
command-line

Srinivas Ramana (1):
arm64: Defer enabling pointer authentication on boot core

 .../admin-guide/kernel-parameters.txt         |   9 +
 Documentation/virt/kvm/arm/hyp-abi.rst        |   9 +
 arch/arm64/include/asm/assembler.h            |  17 ++
 arch/arm64/include/asm/cpufeature.h           |  11 +
 arch/arm64/include/asm/el2_setup.h            |  60 ++----
 arch/arm64/include/asm/pointer_auth.h         |  10 +
 arch/arm64/include/asm/setup.h                |  11 +
 arch/arm64/include/asm/stackprotector.h       |   1 +
 arch/arm64/include/asm/virt.h                 |   7 +-
 arch/arm64/kernel/Makefile                    |   2 +-
 arch/arm64/kernel/asm-offsets.c               |   3 +
 arch/arm64/kernel/cpufeature.c                |  70 +++++-
 arch/arm64/kernel/head.S                      |  75 ++-----
 arch/arm64/kernel/hyp-stub.S                  | 133 +++++++++++-
 arch/arm64/kernel/idreg-override.c            | 202 ++++++++++++++++++
 arch/arm64/kernel/kaslr.c                     |  43 +---
 arch/arm64/kernel/setup.c                     |  15 ++
 arch/arm64/kernel/sleep.S                     |   1 +
 arch/arm64/kvm/arm.c                          |   3 +
 arch/arm64/kvm/hyp/nvhe/hyp-init.S            |   2 +-
 arch/arm64/mm/mmu.c                           |   2 +-
 arch/arm64/mm/proc.S                          |  16 +-
 22 files changed, 532 insertions(+), 170 deletions(-)
 create mode 100644 arch/arm64/include/asm/setup.h
 create mode 100644 arch/arm64/kernel/idreg-override.c
Signature · 6 lines
2.29.2

_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
author maintainer
#1 lore raw

PATCH v5 1/21 arm64: Fix labels in el2_setup macros

If someone happens to write the following code:

	b	1f
	init_el2_state	vhe
1:
	[...]

they will be in for a long debugging session, as the label "1f" will be resolved *inside* the init_el2_state macro instead of after it. Not really what one expects.

Instead, rewite the EL2 setup macros to use unambiguous labels, thanks to the usual macro counter trick.

---
 arch/arm64/include/asm/el2_setup.h | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)
arch/arm64/include/asm/el2_setup.h +12 -12
index a7f5a1bbc8ac..540116de80bf 100644
@@ -45,24 +45,24 @@
 	mrs	x1, id_aa64dfr0_el1
 	sbfx	x0, x1, #ID_AA64DFR0_PMUVER_SHIFT, #4
 	cmp	x0, #1
-	b.lt	1f				// Skip if no PMU present
+	b.lt	.Lskip_pmu_\@			// Skip if no PMU present
 	mrs	x0, pmcr_el0			// Disable debug access traps
 	ubfx	x0, x0, #11, #5			// to EL2 and allow access to
-1:
+.Lskip_pmu_\@:
 	csel	x2, xzr, x0, lt			// all PMU counters from EL1
 
 	/* Statistical profiling */
 	ubfx	x0, x1, #ID_AA64DFR0_PMSVER_SHIFT, #4
-	cbz	x0, 3f				// Skip if SPE not present
+	cbz	x0, .Lskip_spe_\@		// Skip if SPE not present
 
 .ifeqs "\mode", "nvhe"
 	mrs_s	x0, SYS_PMBIDR_EL1              // If SPE available at EL2,
 	and	x0, x0, #(1 << SYS_PMBIDR_EL1_P_SHIFT)
-	cbnz	x0, 2f				// then permit sampling of physical
+	cbnz	x0, .Lskip_spe_el2_\@		// then permit sampling of physical
 	mov	x0, #(1 << SYS_PMSCR_EL2_PCT_SHIFT | \
 		      1 << SYS_PMSCR_EL2_PA_SHIFT)
 	msr_s	SYS_PMSCR_EL2, x0		// addresses and physical counter
-2:
+.Lskip_spe_el2_\@:
 	mov	x0, #(MDCR_EL2_E2PB_MASK << MDCR_EL2_E2PB_SHIFT)
 	orr	x2, x2, x0			// If we don't have VHE, then
 						// use EL1&0 translation.
@@ -71,7 +71,7 @@
 						// and disable access from EL1
 .endif
 
-3:
+.Lskip_spe_\@:
 	msr	mdcr_el2, x2			// Configure debug traps
 .endm
 
@@ -79,9 +79,9 @@
 .macro __init_el2_lor
 	mrs	x1, id_aa64mmfr1_el1
 	ubfx	x0, x1, #ID_AA64MMFR1_LOR_SHIFT, 4
-	cbz	x0, 1f
+	cbz	x0, .Lskip_lor_\@
 	msr_s	SYS_LORC_EL1, xzr
-1:
+.Lskip_lor_\@:
 .endm
 
 /* Stage-2 translation */
@@ -93,7 +93,7 @@
 .macro __init_el2_gicv3
 	mrs	x0, id_aa64pfr0_el1
 	ubfx	x0, x0, #ID_AA64PFR0_GIC_SHIFT, #4
-	cbz	x0, 1f
+	cbz	x0, .Lskip_gicv3_\@
 
 	mrs_s	x0, SYS_ICC_SRE_EL2
 	orr	x0, x0, #ICC_SRE_EL2_SRE	// Set ICC_SRE_EL2.SRE==1
@@ -103,7 +103,7 @@
 	mrs_s	x0, SYS_ICC_SRE_EL2		// Read SRE back,
 	tbz	x0, #0, 1f			// and check that it sticks
 	msr_s	SYS_ICH_HCR_EL2, xzr		// Reset ICC_HCR_EL2 to defaults
-1:
+.Lskip_gicv3_\@:
 .endm
 
 .macro __init_el2_hstr
@@ -128,14 +128,14 @@
 .macro __init_el2_nvhe_sve
 	mrs	x1, id_aa64pfr0_el1
 	ubfx	x1, x1, #ID_AA64PFR0_SVE_SHIFT, #4
-	cbz	x1, 1f
+	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.
-1:
+.Lskip_sve_\@:
 .endm
 
 .macro __init_el2_nvhe_prepare_eret
Signature · 6 lines
2.29.2

_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
author maintainer
#2 lore raw

PATCH v5 2/21 arm64: Fix outdated TCR setup comment

In reply to Marc Zyngier

The arm64 kernel has long be able to use more than 39bit VAs. Since day one, actually. Let's rewrite the offending comment.

---
 arch/arm64/mm/proc.S | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
arch/arm64/mm/proc.S +2 -2
index 1f7ee8c8b7b8..ece785477bdc 100644
@@ -464,8 +464,8 @@ SYM_FUNC_START(__cpu_setup)
 #endif
 	msr	mair_el1, x5
 	/*
-	 * Set/prepare TCR and TTBR. We use 512GB (39-bit) address range for
-	 * both user and kernel.
+	 * Set/prepare TCR and TTBR. TCR_EL1.T1SZ gets further
+	 * adjusted if the kernel is compiled with 52bit VA support.
 	 */
 	mov_q	x10, TCR_TxSZ(VA_BITS) | TCR_CACHE_FLAGS | TCR_SMP_FLAGS | \
 			TCR_TG_FLAGS | TCR_KASLR_FLAGS | TCR_ASID16 | \
Signature · 6 lines
2.29.2

_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
author maintainer
#3 lore raw

PATCH v5 3/21 arm64: Turn the MMU-on sequence into a macro

In reply to Marc Zyngier

Turning the MMU on is a popular sport in the arm64 kernel, and we do it more than once, or even twice. As we are about to add even more, let's turn it into a macro.

No expected functional change.

---
 arch/arm64/include/asm/assembler.h | 17 +++++++++++++++++
 arch/arm64/kernel/head.S           | 19 ++++---------------
 arch/arm64/mm/proc.S               | 12 +-----------
 3 files changed, 22 insertions(+), 26 deletions(-)
arch/arm64/include/asm/assembler.h +17 -0
index bf125c591116..8cded93f99c3 100644
@@ -675,6 +675,23 @@ USER(\label, ic	ivau, \tmp2)			// invalidate I line PoU
 	.endif
 	.endm
 
+/*
+ * Set SCTLR_EL1 to the passed value, and invalidate the local icache
+ * in the process. This is called when setting the MMU on.
+ */
+.macro set_sctlr_el1, reg
+	msr	sctlr_el1, \reg
+	isb
+	/*
+	 * Invalidate the local I-cache so that any instructions fetched
+	 * speculatively from the PoC are discarded, since they may have
+	 * been dynamically patched at the PoU.
+	 */
+	ic	iallu
+	dsb	nsh
+	isb
+.endm
+
 /*
  * Check whether to yield to another runnable task from kernel mode NEON code
  * (which runs with preemption disabled).
arch/arm64/kernel/head.S +4 -15
index a0dc987724ed..28e9735302df 100644
@@ -703,16 +703,9 @@ SYM_FUNC_START(__enable_mmu)
 	offset_ttbr1 x1, x3
 	msr	ttbr1_el1, x1			// load TTBR1
 	isb
-	msr	sctlr_el1, x0
-	isb
-	/*
-	 * Invalidate the local I-cache so that any instructions fetched
-	 * speculatively from the PoC are discarded, since they may have
-	 * been dynamically patched at the PoU.
-	 */
-	ic	iallu
-	dsb	nsh
-	isb
+
+	set_sctlr_el1	x0
+
 	ret
 SYM_FUNC_END(__enable_mmu)
 
@@ -883,11 +876,7 @@ SYM_FUNC_START_LOCAL(__primary_switch)
 	tlbi	vmalle1				// Remove any stale TLB entries
 	dsb	nsh
 
-	msr	sctlr_el1, x19			// re-enable the MMU
-	isb
-	ic	iallu				// flush instructions fetched
-	dsb	nsh				// via old mapping
-	isb
+	set_sctlr_el1	x19			// re-enable the MMU
 
 	bl	__relocate_kernel
 #endif
arch/arm64/mm/proc.S +1 -11
index ece785477bdc..c967bfd30d2b 100644
@@ -291,17 +291,7 @@ skip_pgd:
 	/* We're done: fire up the MMU again */
 	mrs	x17, sctlr_el1
 	orr	x17, x17, #SCTLR_ELx_M
-	msr	sctlr_el1, x17
-	isb
-
-	/*
-	 * Invalidate the local I-cache so that any instructions fetched
-	 * speculatively from the PoC are discarded, since they may have
-	 * been dynamically patched at the PoU.
-	 */
-	ic	iallu
-	dsb	nsh
-	isb
+	set_sctlr_el1	x17
 
 	/* Set the flag to zero to indicate that we're all done */
 	str	wzr, [flag_ptr]
Signature · 6 lines
2.29.2

_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
author maintainer
#4 lore raw

PATCH v5 4/21 arm64: Provide an 'upgrade to VHE' stub hypercall

In reply to Marc Zyngier

As we are about to change the way a VHE system boots, let's provide the core helper, in the form of a stub hypercall that enables VHE and replicates the full EL1 context at EL2, thanks to EL1 and VHE-EL2 being extremely similar.

On exception return, the kernel carries on at EL2. Fancy!

Nothing calls this new hypercall yet, so no functional change.

---
 arch/arm64/include/asm/virt.h |  7 +++-
 arch/arm64/kernel/hyp-stub.S  | 76 ++++++++++++++++++++++++++++++++++-
 2 files changed, 80 insertions(+), 3 deletions(-)
arch/arm64/include/asm/virt.h +6 -1
index ee6a48df89d9..7379f35ae2c6 100644
@@ -35,8 +35,13 @@
  */
 #define HVC_RESET_VECTORS 2
 
+/*
+ * HVC_VHE_RESTART - Upgrade the CPU from EL1 to EL2, if possible
+ */
+#define HVC_VHE_RESTART	3
+
 /* Max number of HYP stub hypercalls */
-#define HVC_STUB_HCALL_NR 3
+#define HVC_STUB_HCALL_NR 4
 
 /* Error returned when an invalid stub number is passed into x0 */
 #define HVC_STUB_ERR	0xbadca11
arch/arm64/kernel/hyp-stub.S +74 -2

99 lines not on this page · raw message

Signature · 6 lines
2.29.2

_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
maintainer Acked-by on v5 4/21
#5 lore raw

Re: [PATCH v5 04/21] arm64: Provide an 'upgrade to VHE' stub hypercall

Quoted 11 lines · Marc Zyngier

As we are about to change the way a VHE system boots, let's provide the core helper, in the form of a stub hypercall that enables VHE and replicates the full EL1 context at EL2, thanks to EL1 and VHE-EL2 being extremely similar.

On exception return, the kernel carries on at EL2. Fancy!

Nothing calls this new hypercall yet, so no functional change.

_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

author maintainer
#6 lore raw

PATCH v5 5/21 arm64: Initialise as nVHE before switching to VHE

In reply to Marc Zyngier

As we are aiming to be able to control whether we enable VHE or not, let's always drop down to EL1 first, and only then upgrade to VHE if at all possible.

This means that if the kernel is booted at EL2, we always start with a nVHE init, drop to EL1 to initialise the the kernel, and only then upgrade the kernel EL to EL2 if possible (the process is obviously shortened for secondary CPUs).

The resume path is handled similarly to a secondary CPU boot.

---
 arch/arm64/kernel/head.S     | 38 ++----------------------------------
 arch/arm64/kernel/hyp-stub.S | 24 +++++++++++++++++++++++
 arch/arm64/kernel/sleep.S    |  1 +
 3 files changed, 27 insertions(+), 36 deletions(-)
arch/arm64/kernel/head.S +2 -36
index 28e9735302df..07445fd976ef 100644
@@ -433,6 +433,7 @@ SYM_FUNC_START_LOCAL(__primary_switched)
 	bl	__pi_memset
 	dsb	ishst				// Make zero page visible to PTW
 
+	bl	switch_to_vhe
 #if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
 	bl	kasan_early_init
 #endif
@@ -493,42 +494,6 @@ SYM_INNER_LABEL(init_el1, SYM_L_LOCAL)
 	eret
 
 SYM_INNER_LABEL(init_el2, SYM_L_LOCAL)
-#ifdef CONFIG_ARM64_VHE
-	/*
-	 * Check for VHE being present. x2 being non-zero indicates that we
-	 * do have VHE, and that the kernel is intended to run at EL2.
-	 */
-	mrs	x2, id_aa64mmfr1_el1
-	ubfx	x2, x2, #ID_AA64MMFR1_VHE_SHIFT, #4
-#else
-	mov	x2, xzr
-#endif
-	cbz	x2, init_el2_nvhe
-
-	/*
-	 * When VHE _is_ in use, EL1 will not be used in the host and
-	 * requires no configuration, and all non-hyp-specific EL2 setup
-	 * will be done via the _EL1 system register aliases in __cpu_setup.
-	 */
-	mov_q	x0, HCR_HOST_VHE_FLAGS
-	msr	hcr_el2, x0
-	isb
-
-	init_el2_state vhe
-
-	isb
-
-	mov_q	x0, INIT_PSTATE_EL2
-	msr	spsr_el2, x0
-	msr	elr_el2, lr
-	mov	w0, #BOOT_CPU_MODE_EL2
-	eret
-
-SYM_INNER_LABEL(init_el2_nvhe, SYM_L_LOCAL)
-	/*
-	 * When VHE is not in use, early init of EL2 and EL1 needs to be
-	 * done here.
-	 */
 	mov_q	x0, INIT_SCTLR_EL1_MMU_OFF
 	msr	sctlr_el1, x0
 
@@ -623,6 +588,7 @@ SYM_FUNC_START_LOCAL(secondary_startup)
 	/*
 	 * Common entry point for secondary CPUs.
 	 */
+	bl	switch_to_vhe
 	bl	__cpu_secondary_check52bitva
 	bl	__cpu_setup			// initialise processor
 	adrp	x1, swapper_pg_dir
arch/arm64/kernel/hyp-stub.S +24 -0
index 3f3dbbe8914d..373ed2213e1d 100644
@@ -190,3 +190,27 @@ SYM_FUNC_START(__hyp_reset_vectors)
 	hvc	#0
 	ret
 SYM_FUNC_END(__hyp_reset_vectors)
+
+/*
+ * Entry point to switch to VHE if deemed capable
+ */
+SYM_FUNC_START(switch_to_vhe)
+#ifdef CONFIG_ARM64_VHE
+	// Need to have booted at EL2
+	adr_l	x1, __boot_cpu_mode
+	ldr	w0, [x1]
+	cmp	w0, #BOOT_CPU_MODE_EL2
+	b.ne	1f
+
+	// and still be at EL1
+	mrs	x0, CurrentEL
+	cmp	x0, #CurrentEL_EL1
+	b.ne	1f
+
+	// Turn the world upside down
+	mov	x0, #HVC_VHE_RESTART
+	hvc	#0
+1:
+#endif
+	ret
+SYM_FUNC_END(switch_to_vhe)
arch/arm64/kernel/sleep.S +1 -0
index 6bdef7362c0e..5bfd9b87f85d 100644
@@ -100,6 +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	__cpu_setup
 	/* enable the MMU early - so we can access sleep_save_stash by va */
 	adrp	x1, swapper_pg_dir
Signature · 6 lines
2.29.2

_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
maintainer Acked-by on v5 5/21
#7 lore raw

Re: [PATCH v5 05/21] arm64: Initialise as nVHE before switching to VHE

Quoted 9 lines · Marc Zyngier

As we are aiming to be able to control whether we enable VHE or not, let's always drop down to EL1 first, and only then upgrade to VHE if at all possible.

This means that if the kernel is booted at EL2, we always start with a nVHE init, drop to EL1 to initialise the the kernel, and only then upgrade the kernel EL to EL2 if possible (the process is obviously shortened for secondary CPUs).

Quoted 4 lines

The resume path is handled similarly to a secondary CPU boot.

_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

author maintainer
#8 lore raw

PATCH v5 6/21 arm64: Move VHE-specific SPE setup to mutate_to_vhe()

In reply to Marc Zyngier

There isn't much that a VHE kernel needs on top of whatever has been done for nVHE, so let's move the little we need to the VHE stub (the SPE setup), and drop the init_el2_state macro.

No expected functional change.

---
 arch/arm64/kernel/hyp-stub.S | 28 +++++++++++++++++++++++++---
 1 file changed, 25 insertions(+), 3 deletions(-)
arch/arm64/kernel/hyp-stub.S +25 -3
index 373ed2213e1d..6b5c73cf9d52 100644
@@ -92,9 +92,6 @@ SYM_CODE_START_LOCAL(mutate_to_vhe)
 	msr	hcr_el2, x0
 	isb
 
-	// Doesn't do much on VHE, but still, worth a shot
-	init_el2_state vhe
-
 	// Use the EL1 allocated stack, per-cpu offset
 	mrs	x0, sp_el1
 	mov	sp, x0
@@ -107,6 +104,31 @@ SYM_CODE_START_LOCAL(mutate_to_vhe)
 	mrs_s	x0, SYS_VBAR_EL12
 	msr	vbar_el1, x0
 
+	// Fixup SPE configuration, if supported...
+	mrs	x1, id_aa64dfr0_el1
+	ubfx	x1, x1, #ID_AA64DFR0_PMSVER_SHIFT, #4
+	mov	x2, xzr
+	cbz	x1, skip_spe
+
+	// ... and not owned by EL3
+	mrs_s	x0, SYS_PMBIDR_EL1
+	and	x0, x0, #(1 << SYS_PMBIDR_EL1_P_SHIFT)
+	cbnz	x0, skip_spe
+
+	// Let the SPE driver in control of the sampling
+	mrs_s	x0, SYS_PMSCR_EL1
+	bic	x0, x0, #(1 << SYS_PMSCR_EL2_PCT_SHIFT)
+	bic	x0, x0, #(1 << SYS_PMSCR_EL2_PA_SHIFT)
+	msr_s	SYS_PMSCR_EL1, x0
+	mov	x2, #MDCR_EL2_TPMS
+
+skip_spe:
+	// For VHE, use EL2 translation and disable access from EL1
+	mrs	x0, mdcr_el2
+	bic	x0, x0, #(MDCR_EL2_E2PB_MASK << MDCR_EL2_E2PB_SHIFT)
+	orr	x0, x0, x2
+	msr	mdcr_el2, x0
+
 	// Transfer the MM state from EL1 to EL2
 	mrs_s	x0, SYS_TCR_EL12
 	msr	tcr_el1, x0
Signature · 6 lines
2.29.2

_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
maintainer Acked-by on v5 6/21
#9 lore raw

Re: [PATCH v5 06/21] arm64: Move VHE-specific SPE setup to mutate_to_vhe()

Quoted 8 lines · Marc Zyngier

There isn't much that a VHE kernel needs on top of whatever has been done for nVHE, so let's move the little we need to the VHE stub (the SPE setup), and drop the init_el2_state macro.

No expected functional change.

_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

author maintainer
#10 lore raw

PATCH v5 7/21 arm64: Simplify init_el2_state to be non-VHE only

In reply to Marc Zyngier

As init_el2_state is now nVHE only, let's simplify it and drop the VHE setup.

---
 arch/arm64/include/asm/el2_setup.h | 36 +++++++-----------------------
 arch/arm64/kernel/head.S           |  2 +-
 arch/arm64/kvm/hyp/nvhe/hyp-init.S |  2 +-
 3 files changed, 10 insertions(+), 30 deletions(-)
arch/arm64/include/asm/el2_setup.h +8 -28
index 540116de80bf..d77d358f9395 100644
@@ -32,16 +32,14 @@
  * to transparently mess with the EL0 bits via CNTKCTL_EL1 access in
  * EL2.
  */
-.macro __init_el2_timers mode
-.ifeqs "\mode", "nvhe"
+.macro __init_el2_timers
 	mrs	x0, cnthctl_el2
 	orr	x0, x0, #3			// Enable EL1 physical timers
 	msr	cnthctl_el2, x0
-.endif
 	msr	cntvoff_el2, xzr		// Clear virtual offset
 .endm
 
-.macro __init_el2_debug mode
+.macro __init_el2_debug
 	mrs	x1, id_aa64dfr0_el1
 	sbfx	x0, x1, #ID_AA64DFR0_PMUVER_SHIFT, #4
 	cmp	x0, #1
@@ -55,7 +53,6 @@
 	ubfx	x0, x1, #ID_AA64DFR0_PMSVER_SHIFT, #4
 	cbz	x0, .Lskip_spe_\@		// Skip if SPE not present
 
-.ifeqs "\mode", "nvhe"
 	mrs_s	x0, SYS_PMBIDR_EL1              // If SPE available at EL2,
 	and	x0, x0, #(1 << SYS_PMBIDR_EL1_P_SHIFT)
 	cbnz	x0, .Lskip_spe_el2_\@		// then permit sampling of physical
@@ -66,10 +63,6 @@
 	mov	x0, #(MDCR_EL2_E2PB_MASK << MDCR_EL2_E2PB_SHIFT)
 	orr	x2, x2, x0			// If we don't have VHE, then
 						// use EL1&0 translation.
-.else
-	orr	x2, x2, #MDCR_EL2_TPMS		// For VHE, use EL2 translation
-						// and disable access from EL1
-.endif
 
 .Lskip_spe_\@:
 	msr	mdcr_el2, x2			// Configure debug traps
@@ -145,37 +138,24 @@
 
 /**
  * Initialize EL2 registers to sane values. This should be called early on all
- * cores that were booted in EL2.
+ * cores that were booted in EL2. Note that everything gets initialised as
+ * if VHE was not evailable. The kernel context will be upgraded to VHE
+ * if possible later on in the boot process
  *
  * Regs: x0, x1 and x2 are clobbered.
  */
-.macro init_el2_state mode
-.ifnes "\mode", "vhe"
-.ifnes "\mode", "nvhe"
-.error "Invalid 'mode' argument"
-.endif
-.endif
-
+.macro init_el2_state
 	__init_el2_sctlr
-	__init_el2_timers \mode
-	__init_el2_debug \mode
+	__init_el2_timers
+	__init_el2_debug
 	__init_el2_lor
 	__init_el2_stage2
 	__init_el2_gicv3
 	__init_el2_hstr
-
-	/*
-	 * When VHE is not in use, early init of EL2 needs to be done here.
-	 * When VHE _is_ in use, EL1 will not be used in the host and
-	 * requires no configuration, and all non-hyp-specific EL2 setup
-	 * will be done via the _EL1 system register aliases in __cpu_setup.
-	 */
-.ifeqs "\mode", "nvhe"
 	__init_el2_nvhe_idregs
 	__init_el2_nvhe_cptr
 	__init_el2_nvhe_sve
 	__init_el2_nvhe_prepare_eret
-.endif
 .endm
 
 #endif /* __ARM_KVM_INIT_H__ */
arch/arm64/kernel/head.S +1 -1
index 07445fd976ef..36212c05df42 100644
@@ -501,7 +501,7 @@ SYM_INNER_LABEL(init_el2, SYM_L_LOCAL)
 	msr	hcr_el2, x0
 	isb
 
-	init_el2_state nvhe
+	init_el2_state
 
 	/* Hypervisor stub */
 	adr_l	x0, __hyp_stub_vectors
arch/arm64/kvm/hyp/nvhe/hyp-init.S +1 -1
index 31b060a44045..222cfc3e7190 100644
@@ -189,7 +189,7 @@ SYM_CODE_START_LOCAL(__kvm_hyp_init_cpu)
 2:	msr	SPsel, #1			// We want to use SP_EL{1,2}
 
 	/* Initialize EL2 CPU state to sane values. */
-	init_el2_state nvhe			// Clobbers x0..x2
+	init_el2_state				// Clobbers x0..x2
 
 	/* Enable MMU, set vectors and stack. */
 	mov	x0, x28
Signature · 6 lines
2.29.2

_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
maintainer Acked-by on v5 7/21
#11 lore raw

Re: [PATCH v5 07/21] arm64: Simplify init_el2_state to be non-VHE only

Quoted 5 lines · Marc Zyngier

As init_el2_state is now nVHE only, let's simplify it and drop the VHE setup.

_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

author maintainer
#12 lore raw

PATCH v5 8/21 arm64: Move SCTLR_EL1 initialisation to EL-agnostic code

In reply to Marc Zyngier

We can now move the initial SCTLR_EL1 setup to be used for both EL1 and EL2 setup.

---
 arch/arm64/kernel/head.S | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)
arch/arm64/kernel/head.S +3 -5
index 36212c05df42..b425d2587cdb 100644
@@ -479,13 +479,14 @@ EXPORT_SYMBOL(kimage_vaddr)
  * booted in EL1 or EL2 respectively.
  */
 SYM_FUNC_START(init_kernel_el)
+	mov_q	x0, INIT_SCTLR_EL1_MMU_OFF
+	msr	sctlr_el1, x0
+
 	mrs	x0, CurrentEL
 	cmp	x0, #CurrentEL_EL2
 	b.eq	init_el2
 
 SYM_INNER_LABEL(init_el1, SYM_L_LOCAL)
-	mov_q	x0, INIT_SCTLR_EL1_MMU_OFF
-	msr	sctlr_el1, x0
 	isb
 	mov_q	x0, INIT_PSTATE_EL1
 	msr	spsr_el1, x0
@@ -494,9 +495,6 @@ SYM_INNER_LABEL(init_el1, SYM_L_LOCAL)
 	eret
 
 SYM_INNER_LABEL(init_el2, SYM_L_LOCAL)
-	mov_q	x0, INIT_SCTLR_EL1_MMU_OFF
-	msr	sctlr_el1, x0
-
 	mov_q	x0, HCR_HOST_NVHE_FLAGS
 	msr	hcr_el2, x0
 	isb
Signature · 6 lines
2.29.2

_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
author maintainer
#13 lore raw

PATCH v5 9/21 arm64: cpufeature: Add global feature override facility

In reply to Marc Zyngier

Add a facility to globally override a feature, no matter what the HW says. Yes, this sounds dangerous, but we do respect the "safe" value for a given feature. This doesn't mean the user doesn't need to know what they are doing.

Nothing uses this yet, so we are pretty safe. For now.

---
 arch/arm64/include/asm/cpufeature.h |  6 +++++
 arch/arm64/kernel/cpufeature.c      | 42 ++++++++++++++++++++++++-----
 2 files changed, 42 insertions(+), 6 deletions(-)
arch/arm64/include/asm/cpufeature.h +6 -0
index 9a555809b89c..fe469389068e 100644
@@ -63,6 +63,11 @@ struct arm64_ftr_bits {
 	s64		safe_val; /* safe value for FTR_EXACT features */
 };
 
+struct arm64_ftr_override {
+	u64		val;
+	u64		mask;
+};
+
 /*
  * @arm64_ftr_reg - Feature register
  * @strict_mask		Bits which should match across all CPUs for sanity.
@@ -74,6 +79,7 @@ struct arm64_ftr_reg {
 	u64				user_mask;
 	u64				sys_val;
 	u64				user_val;
+	struct arm64_ftr_override 	*override;
 	const struct arm64_ftr_bits	*ftr_bits;
 };
 
arch/arm64/kernel/cpufeature.c +36 -6

64 lines not on this page · raw message

Signature · 6 lines
2.29.2

_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
maintainer Reviewed-by on v5 9/21
#14 lore raw

Re: [PATCH v5 09/21] arm64: cpufeature: Add global feature override facility

Quoted 10 lines · Marc Zyngier

Add a facility to globally override a feature, no matter what the HW says. Yes, this sounds dangerous, but we do respect the "safe" value for a given feature. This doesn't mean the user doesn't need to know what they are doing.

Nothing uses this yet, so we are pretty safe. For now.

That's more readable with a single pointer.

_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

author maintainer
#15 lore raw

PATCH v5 10/21 arm64: cpufeature: Use IDreg override in __read_sysreg_by_encoding()

In reply to Marc Zyngier

__read_sysreg_by_encoding() is used by a bunch of cpufeature helpers, which should take the feature override into account. Let's do that.

For a good measure (and because we are likely to need to further down the line), make this helper available to the rest of the non-modular kernel.

Code that needs to know the *real* features of a CPU can still use read_sysreg_s(), and find the bare, ugly truth.

---
 arch/arm64/include/asm/cpufeature.h |  1 +
 arch/arm64/kernel/cpufeature.c      | 15 +++++++++++++--
 2 files changed, 14 insertions(+), 2 deletions(-)
arch/arm64/include/asm/cpufeature.h +1 -0
index fe469389068e..4179cfc8ed57 100644
@@ -606,6 +606,7 @@ void __init setup_cpu_features(void);
 void check_local_cpu_capabilities(void);
 
 u64 read_sanitised_ftr_reg(u32 id);
+u64 __read_sysreg_by_encoding(u32 sys_id);
 
 static inline bool cpu_supports_mixed_endian_el0(void)
 {
arch/arm64/kernel/cpufeature.c +13 -2
index cb58c7c991ef..4b84a1e1dc51 100644
@@ -1145,14 +1145,17 @@ u64 read_sanitised_ftr_reg(u32 id)
 EXPORT_SYMBOL_GPL(read_sanitised_ftr_reg);
 
 #define read_sysreg_case(r)	\
-	case r:		return read_sysreg_s(r)
+	case r:		val = read_sysreg_s(r); break;
 
 /*
  * __read_sysreg_by_encoding() - Used by a STARTING cpu before cpuinfo is populated.
  * Read the system register on the current CPU
  */
-static u64 __read_sysreg_by_encoding(u32 sys_id)
+u64 __read_sysreg_by_encoding(u32 sys_id)
 {
+	struct arm64_ftr_reg *regp;
+	u64 val;
+
 	switch (sys_id) {
 	read_sysreg_case(SYS_ID_PFR0_EL1);
 	read_sysreg_case(SYS_ID_PFR1_EL1);
@@ -1195,6 +1198,14 @@ static u64 __read_sysreg_by_encoding(u32 sys_id)
 		BUG();
 		return 0;
 	}
+
+	regp  = get_arm64_ftr_reg(sys_id);
+	if (regp) {
+		val &= ~regp->override->mask;
+		val |= (regp->override->val & regp->override->mask);
+	}
+
+	return val;
 }
 
 #include <linux/irqchip/arm-gic-v3.h>
Signature · 6 lines
2.29.2

_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
maintainer Reviewed-by on v5 10/21
#16 lore raw

Re: [PATCH v5 10/21] arm64: cpufeature: Use IDreg override in __read_sysreg_by_encoding()

Quoted 7 lines · Marc Zyngier

__read_sysreg_by_encoding() is used by a bunch of cpufeature helpers, which should take the feature override into account. Let's do that.

For a good measure (and because we are likely to need to further down the line), make this helper available to the rest of the non-modular kernel.

Quoted 6 lines

Code that needs to know the *real* features of a CPU can still use read_sysreg_s(), and find the bare, ugly truth.

_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

author maintainer
#17 lore raw

PATCH v5 11/21 arm64: Extract early FDT mapping from kaslr_early_init()

In reply to Marc Zyngier

As we want to parse more options very early in the kernel lifetime, let's always map the FDT early. This is achieved by moving that code out of kaslr_early_init().

No functionnal change expected.

---
 arch/arm64/include/asm/setup.h | 11 +++++++++++
 arch/arm64/kernel/head.S       |  3 ++-
 arch/arm64/kernel/kaslr.c      |  7 +++----
 arch/arm64/kernel/setup.c      | 15 +++++++++++++++
 4 files changed, 31 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm64/include/asm/setup.h
arch/arm64/include/asm/setup.h new file +11 -0
new file mode 100644
index 000000000000..d3320618ed14
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#ifndef __ARM64_ASM_SETUP_H
+#define __ARM64_ASM_SETUP_H
+
+#include <uapi/asm/setup.h>
+
+void *get_early_fdt_ptr(void);
+void early_fdt_map(u64 dt_phys);
+
+#endif
arch/arm64/kernel/head.S +2 -1
index b425d2587cdb..d74e5f84042e 100644
@@ -433,6 +433,8 @@ SYM_FUNC_START_LOCAL(__primary_switched)
 	bl	__pi_memset
 	dsb	ishst				// Make zero page visible to PTW
 
+	mov	x0, x21				// pass FDT address in x0
+	bl	early_fdt_map			// Try mapping the FDT early
 	bl	switch_to_vhe
 #if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
 	bl	kasan_early_init
@@ -440,7 +442,6 @@ SYM_FUNC_START_LOCAL(__primary_switched)
 #ifdef CONFIG_RANDOMIZE_BASE
 	tst	x23, ~(MIN_KIMG_ALIGN - 1)	// already running randomized?
 	b.ne	0f
-	mov	x0, x21				// pass FDT address in x0
 	bl	kaslr_early_init		// parse FDT for KASLR options
 	cbz	x0, 0f				// KASLR disabled? just proceed
 	orr	x23, x23, x0			// record KASLR offset
arch/arm64/kernel/kaslr.c +3 -4
index 1c74c45b9494..5fc86e7d01a1 100644
@@ -19,6 +19,7 @@
 #include <asm/memory.h>
 #include <asm/mmu.h>
 #include <asm/sections.h>
+#include <asm/setup.h>
 
 enum kaslr_status {
 	KASLR_ENABLED,
@@ -92,12 +93,11 @@ static __init bool is_kaslr_disabled_cmdline(void *fdt)
  * containing function pointers) to be reinitialized, and zero-initialized
  * .bss variables will be reset to 0.
  */
-u64 __init kaslr_early_init(u64 dt_phys)
+u64 __init kaslr_early_init(void)
 {
 	void *fdt;
 	u64 seed, offset, mask, module_range;
 	unsigned long raw;
-	int size;
 
 	/*
 	 * Set a reasonable default for module_alloc_base in case
@@ -111,8 +111,7 @@ u64 __init kaslr_early_init(u64 dt_phys)
 	 * and proceed with KASLR disabled. We will make another
 	 * attempt at mapping the FDT in setup_machine()
 	 */
-	early_fixmap_init();
-	fdt = fixmap_remap_fdt(dt_phys, &size, PAGE_KERNEL);
+	fdt = get_early_fdt_ptr();
 	if (!fdt) {
 		kaslr_status = KASLR_DISABLED_FDT_REMAP;
 		return 0;
arch/arm64/kernel/setup.c +15 -0
index c18aacde8bb0..61845c0821d9 100644
@@ -168,6 +168,21 @@ static void __init smp_build_mpidr_hash(void)
 		pr_warn("Large number of MPIDR hash buckets detected\n");
 }
 
+static void *early_fdt_ptr __initdata;
+
+void __init *get_early_fdt_ptr(void)
+{
+	return early_fdt_ptr;
+}
+
+asmlinkage void __init early_fdt_map(u64 dt_phys)
+{
+	int fdt_size;
+
+	early_fixmap_init();
+	early_fdt_ptr = fixmap_remap_fdt(dt_phys, &fdt_size, PAGE_KERNEL);
+}
+
 static void __init setup_machine_fdt(phys_addr_t dt_phys)
 {
 	int size;
Signature · 6 lines
2.29.2

_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
author maintainer
#18 lore raw

PATCH v5 12/21 arm64: cpufeature: Add an early command-line cpufeature override facility

In reply to Marc Zyngier

In order to be able to override CPU features at boot time, let's add a command line parser that matches options of the form "cpureg.feature=value", and store the corresponding value into the override val/mask pair.

No features are currently defined, so no expected change in functionality.

---
 arch/arm64/kernel/Makefile         |   2 +-
 arch/arm64/kernel/head.S           |   1 +
 arch/arm64/kernel/idreg-override.c | 130 +++++++++++++++++++++++++++++
 3 files changed, 132 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/kernel/idreg-override.c
arch/arm64/kernel/Makefile +1 -1
index 86364ab6f13f..2262f0392857 100644
@@ -17,7 +17,7 @@ obj-y			:= debug-monitors.o entry.o irq.o fpsimd.o		\
 			   return_address.o cpuinfo.o cpu_errata.o		\
 			   cpufeature.o alternative.o cacheinfo.o		\
 			   smp.o smp_spin_table.o topology.o smccc-call.o	\
-			   syscall.o proton-pack.o
+			   syscall.o proton-pack.o idreg-override.o
 
 targets			+= efi-entry.o
 
arch/arm64/kernel/head.S +1 -0
index d74e5f84042e..3243e3ae9bd8 100644
@@ -435,6 +435,7 @@ SYM_FUNC_START_LOCAL(__primary_switched)
 
 	mov	x0, x21				// pass FDT address in x0
 	bl	early_fdt_map			// Try mapping the FDT early
+	bl	init_feature_override
 	bl	switch_to_vhe
 #if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
 	bl	kasan_early_init
arch/arm64/kernel/idreg-override.c new file +130 -0

130 lines not on this page · raw message

Signature · 6 lines
2.29.2

_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
maintainer Reviewed-by on v5 12/21
#19 lore raw

Re: [PATCH v5 12/21] arm64: cpufeature: Add an early command-line cpufeature override facility

Quoted 10 lines · Marc Zyngier

In order to be able to override CPU features at boot time, let's add a command line parser that matches options of the form "cpureg.feature=value", and store the corresponding value into the override val/mask pair.

No features are currently defined, so no expected change in functionality.

_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

author maintainer
#20 lore raw

PATCH v5 13/21 arm64: Allow ID_AA64MMFR1_EL1.VH to be overridden from the command line

In reply to Marc Zyngier

As we want to be able to disable VHE at runtime, let's match "id_aa64mmfr1.vh=" from the command line as an override. This doesn't have much effect yet as our boot code doesn't look at the cpufeature, but only at the HW registers.

---
 arch/arm64/include/asm/cpufeature.h |  2 ++
 arch/arm64/kernel/cpufeature.c      |  5 ++++-
 arch/arm64/kernel/idreg-override.c  | 11 +++++++++++
 3 files changed, 17 insertions(+), 1 deletion(-)
arch/arm64/include/asm/cpufeature.h +2 -0
index 4179cfc8ed57..b0ed37da4067 100644
@@ -818,6 +818,8 @@ static inline unsigned int get_vmid_bits(u64 mmfr1)
 	return 8;
 }
 
+extern struct arm64_ftr_override id_aa64mmfr1_override;
+
 u32 get_kvm_ipa_limit(void);
 void dump_cpu_features(void);
 
arch/arm64/kernel/cpufeature.c +4 -1
index 4b84a1e1dc51..c1d6712c4249 100644
@@ -557,6 +557,8 @@ static const struct arm64_ftr_bits ftr_raz[] = {
 
 #define ARM64_FTR_REG(id, table) ARM64_FTR_REG_OVERRIDE(id, table, &no_override)
 
+struct arm64_ftr_override id_aa64mmfr1_override;
+
 static const struct __ftr_reg_entry {
 	u32			sys_id;
 	struct arm64_ftr_reg 	*reg;
@@ -604,7 +606,8 @@ static const struct __ftr_reg_entry {
 
 	/* Op1 = 0, CRn = 0, CRm = 7 */
 	ARM64_FTR_REG(SYS_ID_AA64MMFR0_EL1, ftr_id_aa64mmfr0),
-	ARM64_FTR_REG(SYS_ID_AA64MMFR1_EL1, ftr_id_aa64mmfr1),
+	ARM64_FTR_REG_OVERRIDE(SYS_ID_AA64MMFR1_EL1, ftr_id_aa64mmfr1,
+			       &id_aa64mmfr1_override),
 	ARM64_FTR_REG(SYS_ID_AA64MMFR2_EL1, ftr_id_aa64mmfr2),
 
 	/* Op1 = 0, CRn = 1, CRm = 2 */
arch/arm64/kernel/idreg-override.c +11 -0
index 2d184d6674fd..489aa274e3ec 100644
@@ -10,6 +10,7 @@
 #include <linux/libfdt.h>
 
 #include <asm/cacheflush.h>
+#include <asm/cpufeature.h>
 #include <asm/setup.h>
 
 struct ftr_set_desc {
@@ -21,7 +22,17 @@ struct ftr_set_desc {
 	} 				fields[];
 };
 
+static const struct ftr_set_desc mmfr1 __initdata = {
+	.name		= "id_aa64mmfr1",
+	.override	= &id_aa64mmfr1_override,
+	.fields		= {
+	        { "vh", ID_AA64MMFR1_VHE_SHIFT },
+		{}
+	},
+};
+
 static const struct ftr_set_desc * const regs[] __initdata = {
+	&mmfr1,
 };
 
 static char *cmdline_contains_option(const char *cmdline, const char *option)
Signature · 6 lines
2.29.2

_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
reviewer Acked-by on v5 13/21
#21 lore raw

Re: [PATCH v5 13/21] arm64: Allow ID_AA64MMFR1_EL1.VH to be overridden from the command line

Quoted 31 lines · Marc Zyngier

As we want to be able to disable VHE at runtime, let's match "id_aa64mmfr1.vh=" from the command line as an override. This doesn't have much effect yet as our boot code doesn't look at the cpufeature, but only at the HW registers.

---
  arch/arm64/include/asm/cpufeature.h |  2 ++
  arch/arm64/kernel/cpufeature.c      |  5 ++++-
  arch/arm64/kernel/idreg-override.c  | 11 +++++++++++
  3 files changed, 17 insertions(+), 1 deletion(-)
arch/arm64/include/asm/cpufeature.h +2 -0
index 4179cfc8ed57..b0ed37da4067 100644
@@ -818,6 +818,8 @@ static inline unsigned int get_vmid_bits(u64 mmfr1)
  	return 8;
  }
 
+extern struct arm64_ftr_override id_aa64mmfr1_override;
+
  u32 get_kvm_ipa_limit(void);
  void dump_cpu_features(void);
 
arch/arm64/kernel/cpufeature.c +0 -0
index 4b84a1e1dc51..c1d6712c4249 100644

arch/arm64/kernel/cpufeature.c static const struct arm64_ftr_bits ftr_raz[] = { · line 560

Quoted 4 lines
arch/arm64/kernel/cpufeature.c +1 -0
@@ -557,6 +557,8 @@ static const struct arm64_ftr_bits ftr_raz[] = {
 
  #define ARM64_FTR_REG(id, table) ARM64_FTR_REG_OVERRIDE(id, table, &no_override)
 
+struct arm64_ftr_override id_aa64mmfr1_override;

Does this need to be ro_after_init ?

Otherwise, looks good to me:

_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

author maintainer
#22 lore raw

Re: [PATCH v5 13/21] arm64: Allow ID_AA64MMFR1_EL1.VH to be overridden from the command line

Quoted 29 lines · Suzuki K Poulose
Quoted 28 lines · Marc Zyngier

As we want to be able to disable VHE at runtime, let's match "id_aa64mmfr1.vh=" from the command line as an override. This doesn't have much effect yet as our boot code doesn't look at the cpufeature, but only at the HW registers.

---
  arch/arm64/include/asm/cpufeature.h |  2 ++
  arch/arm64/kernel/cpufeature.c      |  5 ++++-
  arch/arm64/kernel/idreg-override.c  | 11 +++++++++++
  3 files changed, 17 insertions(+), 1 deletion(-)
arch/arm64/include/asm/cpufeature.h +1 -0
index 4179cfc8ed57..b0ed37da4067 100644
@@ -818,6 +818,8 @@ static inline unsigned int get_vmid_bits(u64 
 mmfr1)
  	return 8;
  }
  +extern struct arm64_ftr_override id_aa64mmfr1_override;
+
  u32 get_kvm_ipa_limit(void);
  void dump_cpu_features(void);
  diff --git a/arch/arm64/kernel/cpufeature.c 

b/arch/arm64/kernel/cpufeature.c
index 4b84a1e1dc51..c1d6712c4249 100644

Quoted 8 lines

arch/arm64/kernel/cpufeature.c static const struct arm64_ftr_bits ftr_raz[] = { · line 559

Quoted 6 lines
arch/arm64/kernel/cpufeature.c +0 -0
@@ -557,6 +557,8 @@ static const struct arm64_ftr_bits ftr_raz[] = {
    #define ARM64_FTR_REG(id, table) ARM64_FTR_REG_OVERRIDE(id, table, 
 &no_override)
  +struct arm64_ftr_override id_aa64mmfr1_override;

Does this need to be ro_after_init ?

Could do, together with the other two override targeting system registers.

Quoted 3 lines

Otherwise, looks good to me:

Thanks,

        M.
Signature · 5 lines
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
maintainer Reviewed-by on v5 13/21
#23 lore raw

Re: [PATCH v5 13/21] arm64: Allow ID_AA64MMFR1_EL1.VH to be overridden from the command line

In reply to Marc Zyngier
Quoted 7 lines · Marc Zyngier

As we want to be able to disable VHE at runtime, let's match "id_aa64mmfr1.vh=" from the command line as an override. This doesn't have much effect yet as our boot code doesn't look at the cpufeature, but only at the HW registers.

_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

author maintainer
#24 lore raw

PATCH v5 14/21 arm64: Honor VHE being disabled from the command-line

In reply to Marc Zyngier

Finally we can check whether VHE is disabled on the command line, and not enable it if that's the user's wish.

---
 arch/arm64/kernel/asm-offsets.c |  3 +++
 arch/arm64/kernel/hyp-stub.S    | 11 +++++++++++
 2 files changed, 14 insertions(+)
arch/arm64/kernel/asm-offsets.c +3 -0
index f42fd9e33981..1add0f21bffe 100644
@@ -99,6 +99,9 @@ int main(void)
   DEFINE(CPU_BOOT_STACK,	offsetof(struct secondary_data, stack));
   DEFINE(CPU_BOOT_TASK,		offsetof(struct secondary_data, task));
   BLANK();
+  DEFINE(FTR_OVR_VAL_OFFSET,	offsetof(struct arm64_ftr_override, val));
+  DEFINE(FTR_OVR_MASK_OFFSET,	offsetof(struct arm64_ftr_override, mask));
+  BLANK();
 #ifdef CONFIG_KVM
   DEFINE(VCPU_CONTEXT,		offsetof(struct kvm_vcpu, arch.ctxt));
   DEFINE(VCPU_FAULT_DISR,	offsetof(struct kvm_vcpu, arch.fault.disr_el1));
arch/arm64/kernel/hyp-stub.S +11 -0
index 6b5c73cf9d52..aa7e8d592295 100644
@@ -87,6 +87,17 @@ SYM_CODE_START_LOCAL(mutate_to_vhe)
 	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
+	cbz	x2, 1f
+
 	// Engage the VHE magic!
 	mov_q	x0, HCR_HOST_VHE_FLAGS
 	msr	hcr_el2, x0
Signature · 6 lines
2.29.2

_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
maintainer Acked-by on v5 14/21
#25 lore raw

Re: [PATCH v5 14/21] arm64: Honor VHE being disabled from the command-line

Quoted 5 lines · Marc Zyngier

Finally we can check whether VHE is disabled on the command line, and not enable it if that's the user's wish.

_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

author maintainer
#26 lore raw

PATCH v5 15/21 arm64: Add an aliasing facility for the idreg override

In reply to Marc Zyngier

In order to map the override of idregs to options that a user can easily understand, let's introduce yet another option array, which maps an option to the corresponding idreg options.

---
 arch/arm64/kernel/idreg-override.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)
arch/arm64/kernel/idreg-override.c +17 -0
index 489aa274e3ec..4fad3fc4d104 100644
@@ -35,6 +35,12 @@ static const struct ftr_set_desc * const regs[] __initdata = {
 	&mmfr1,
 };
 
+static const struct {
+	const char	*alias;
+	const char	*feature;
+} aliases[] __initdata = {
+};
+
 static char *cmdline_contains_option(const char *cmdline, const char *option)
 {
 	char *str = strstr(cmdline, option);
@@ -88,6 +94,15 @@ static void __init match_options(const char *cmdline)
 	}
 }
 
+static __init void match_aliases(const char *cmdline)
+{
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(aliases); i++)
+		if (cmdline_contains_option(cmdline, aliases[i].alias))
+			match_options(aliases[i].feature);
+}
+
 static __init void parse_cmdline(void)
 {
 	if (!IS_ENABLED(CONFIG_CMDLINE_FORCE)) {
@@ -108,6 +123,7 @@ static __init void parse_cmdline(void)
 			goto out;
 
 		match_options(prop);
+		match_aliases(prop);
 
 		if (!IS_ENABLED(CONFIG_CMDLINE_EXTEND))
 			return;
@@ -115,6 +131,7 @@ static __init void parse_cmdline(void)
 
 out:
 	match_options(CONFIG_CMDLINE);
+	match_aliases(CONFIG_CMDLINE);
 }
 
 /* Keep checkers quiet */
Signature · 6 lines
2.29.2

_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
author maintainer
#27 lore raw

PATCH v5 16/21 arm64: Make kvm-arm.mode={nvhe, protected} an alias of id_aa64mmfr1.vh=0

In reply to Marc Zyngier

Admitedly, passing id_aa64mmfr1.vh=0 on the command-line isn't that easy to understand, and it is likely that users would much prefer write "kvm-arm.mode=nvhe", or "...=protected".

So here you go. This has the added advantage that we can now always honor the "kvm-arm.mode=protected" option, even when booting on a VHE system.

---
 Documentation/admin-guide/kernel-parameters.txt | 3 +++
 arch/arm64/kernel/idreg-override.c              | 2 ++
 arch/arm64/kvm/arm.c                            | 3 +++
 3 files changed, 8 insertions(+)
Documentation/admin-guide/kernel-parameters.txt +3 -0
index 9e3cdb271d06..2786fd39a047 100644
@@ -2257,6 +2257,9 @@
 	kvm-arm.mode=
 			[KVM,ARM] Select one of KVM/arm64's modes of operation.
 
+			nvhe: Standard nVHE-based mode, without support for
+			      protected guests.
+
 			protected: nVHE-based mode with support for guests whose
 				   state is kept private from the host.
 				   Not valid if the kernel is running in EL2.
arch/arm64/kernel/idreg-override.c +2 -0
index 4fad3fc4d104..cbb8eaa48742 100644
@@ -39,6 +39,8 @@ static const struct {
 	const char	*alias;
 	const char	*feature;
 } aliases[] __initdata = {
+	{ "kvm-arm.mode=nvhe",		"id_aa64mmfr1.vh=0" },
+	{ "kvm-arm.mode=protected",	"id_aa64mmfr1.vh=0" },
 };
 
 static char *cmdline_contains_option(const char *cmdline, const char *option)
arch/arm64/kvm/arm.c +3 -0
index 04c44853b103..597565a65ca2 100644
@@ -1966,6 +1966,9 @@ static int __init early_kvm_mode_cfg(char *arg)
 		return 0;
 	}
 
+	if (strcmp(arg, "nvhe") == 0 && !WARN_ON(is_kernel_in_hyp_mode()))
+		return 0;
+
 	return -EINVAL;
 }
 early_param("kvm-arm.mode", early_kvm_mode_cfg);
Signature · 6 lines
2.29.2

_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
author maintainer
#28 lore raw

PATCH v5 17/21 KVM: arm64: Document HVC_VHE_RESTART stub hypercall

In reply to Marc Zyngier

For completeness, let's document the HVC_VHE_RESTART stub.

---
 Documentation/virt/kvm/arm/hyp-abi.rst | 9 +++++++++
 1 file changed, 9 insertions(+)
Documentation/virt/kvm/arm/hyp-abi.rst +9 -0
index 83cadd8186fa..4d43fbc25195 100644
@@ -58,6 +58,15 @@ these functions (see arch/arm{,64}/include/asm/virt.h):
   into place (arm64 only), and jump to the restart address while at HYP/EL2.
   This hypercall is not expected to return to its caller.
 
+* ::
+
+    x0 = HVC_VHE_RESTART (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
+  being off, and VHE not being disabled by any other means (command line
+  option, for example).
+
 Any other value of r0/x0 triggers a hypervisor-specific handling,
 which is not documented here.
 
Signature · 6 lines
2.29.2

_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
author maintainer
#29 lore raw

PATCH v5 18/21 arm64: Move "nokaslr" over to the early cpufeature infrastructure

In reply to Marc Zyngier

Given that the early cpufeature infrastructure has borrowed quite a lot of code from the kaslr implementation, let's reimplement the matching of the "nokaslr" option with it.

---
 arch/arm64/kernel/idreg-override.c | 15 +++++++++++++
 arch/arm64/kernel/kaslr.c          | 36 ++----------------------------
 2 files changed, 17 insertions(+), 34 deletions(-)
arch/arm64/kernel/idreg-override.c +15 -0
index cbb8eaa48742..3ccf51b84ba4 100644
@@ -31,8 +31,22 @@ static const struct ftr_set_desc mmfr1 __initdata = {
 	},
 };
 
+extern struct arm64_ftr_override kaslr_feature_override;
+
+static const struct ftr_set_desc kaslr __initdata = {
+	.name		= "kaslr",
+#ifdef CONFIG_RANDOMIZE_BASE
+	.override	= &kaslr_feature_override,
+#endif
+	.fields		= {
+		{ "disabled", 0 },
+		{}
+	},
+};
+
 static const struct ftr_set_desc * const regs[] __initdata = {
 	&mmfr1,
+	&kaslr,
 };
 
 static const struct {
@@ -41,6 +55,7 @@ static const struct {
 } aliases[] __initdata = {
 	{ "kvm-arm.mode=nvhe",		"id_aa64mmfr1.vh=0" },
 	{ "kvm-arm.mode=protected",	"id_aa64mmfr1.vh=0" },
+	{ "nokaslr",			"kaslr.disabled=1" },
 };
 
 static char *cmdline_contains_option(const char *cmdline, const char *option)
arch/arm64/kernel/kaslr.c +2 -34
index 5fc86e7d01a1..27f8939deb1b 100644
@@ -51,39 +51,7 @@ static __init u64 get_kaslr_seed(void *fdt)
 	return ret;
 }
 
-static __init bool cmdline_contains_nokaslr(const u8 *cmdline)
-{
-	const u8 *str;
-
-	str = strstr(cmdline, "nokaslr");
-	return str == cmdline || (str > cmdline && *(str - 1) == ' ');
-}
-
-static __init bool is_kaslr_disabled_cmdline(void *fdt)
-{
-	if (!IS_ENABLED(CONFIG_CMDLINE_FORCE)) {
-		int node;
-		const u8 *prop;
-
-		node = fdt_path_offset(fdt, "/chosen");
-		if (node < 0)
-			goto out;
-
-		prop = fdt_getprop(fdt, node, "bootargs", NULL);
-		if (!prop)
-			goto out;
-
-		if (cmdline_contains_nokaslr(prop))
-			return true;
-
-		if (IS_ENABLED(CONFIG_CMDLINE_EXTEND))
-			goto out;
-
-		return false;
-	}
-out:
-	return cmdline_contains_nokaslr(CONFIG_CMDLINE);
-}
+struct arm64_ftr_override kaslr_feature_override __initdata;
 
 /*
  * This routine will be executed with the kernel mapped at its default virtual
@@ -126,7 +94,7 @@ u64 __init kaslr_early_init(void)
 	 * Check if 'nokaslr' appears on the command line, and
 	 * return 0 if that is the case.
 	 */
-	if (is_kaslr_disabled_cmdline(fdt)) {
+	if (kaslr_feature_override.val & kaslr_feature_override.mask & 0xf) {
 		kaslr_status = KASLR_DISABLED_CMDLINE;
 		return 0;
 	}
Signature · 6 lines
2.29.2

_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
#30 lore raw

Re: [PATCH v5 18/21] arm64: Move "nokaslr" over to the early cpufeature infrastructure

Quoted 18 lines · Marc Zyngier

Given that the early cpufeature infrastructure has borrowed quite a lot of code from the kaslr implementation, let's reimplement the matching of the "nokaslr" option with it.

---
 arch/arm64/kernel/idreg-override.c | 15 +++++++++++++
 arch/arm64/kernel/kaslr.c          | 36 ++----------------------------
 2 files changed, 17 insertions(+), 34 deletions(-)
arch/arm64/kernel/idreg-override.c +0 -0
index cbb8eaa48742..3ccf51b84ba4 100644

arch/arm64/kernel/idreg-override.c static const struct ftr_set_desc mmfr1 __initdata = { · line 36

Quoted 6 lines
arch/arm64/kernel/idreg-override.c +3 -0
@@ -31,8 +31,22 @@ static const struct ftr_set_desc mmfr1 __initdata = {
        },
 };
 
+extern struct arm64_ftr_override kaslr_feature_override;
+
+static const struct ftr_set_desc kaslr __initdata = {

This should be __initconst not __initdata (below too)

Quoted 17 lines
arch/arm64/kernel/idreg-override.c +11 -0
+       .name           = "kaslr",
+#ifdef CONFIG_RANDOMIZE_BASE
+       .override       = &kaslr_feature_override,
+#endif
+       .fields         = {
+               { "disabled", 0 },
+               {}
+       },
+};
+
 static const struct ftr_set_desc * const regs[] __initdata = {
        &mmfr1,
+       &kaslr,
 };
 
 static const struct {

arch/arm64/kernel/idreg-override.c static const struct { · line 60

Quoted 6 lines
arch/arm64/kernel/idreg-override.c +1 -0
@@ -41,6 +55,7 @@ static const struct {
 } aliases[] __initdata = {
        { "kvm-arm.mode=nvhe",          "id_aa64mmfr1.vh=0" },
        { "kvm-arm.mode=protected",     "id_aa64mmfr1.vh=0" },
+       { "nokaslr",                    "kaslr.disabled=1" },
 };
 

This struct now takes up
- ~100 bytes for the characters themselves (which btw are not emitted into __initdata or __initconst)
- 6x8 bytes for the char pointers
- 6x24 bytes for the RELA relocations that annotate these pointers as quantities that need to be relocated at boot (on a kernel built with KASLR)

I know it's only a drop in the ocean, but in this case, where the struct is statically declared and defined only once, and in the same place, we could easily turn this into

static const struct {
char alias[24];
char param[20];
};

and get rid of all the overhead. The only slightly annoying thing is that the array sizes need to be kept in sync with the largest instance appearing in the array, but this is easy when the struct type is declared in the same place where its only instance is defined.

Quoted 56 lines
arch/arm64/kernel/idreg-override.c +0 -0
 static char *cmdline_contains_option(const char *cmdline, const char *option)
arch/arm64/kernel/kaslr.c +2 -35
index 5fc86e7d01a1..27f8939deb1b 100644
@@ -51,39 +51,7 @@ static __init u64 get_kaslr_seed(void *fdt)
        return ret;
 }
 
-static __init bool cmdline_contains_nokaslr(const u8 *cmdline)
-{
-       const u8 *str;
-
-       str = strstr(cmdline, "nokaslr");
-       return str == cmdline || (str > cmdline && *(str - 1) == ' ');
-}
-
-static __init bool is_kaslr_disabled_cmdline(void *fdt)
-{
-       if (!IS_ENABLED(CONFIG_CMDLINE_FORCE)) {
-               int node;
-               const u8 *prop;
-
-               node = fdt_path_offset(fdt, "/chosen");
-               if (node < 0)
-                       goto out;
-
-               prop = fdt_getprop(fdt, node, "bootargs", NULL);
-               if (!prop)
-                       goto out;
-
-               if (cmdline_contains_nokaslr(prop))
-                       return true;
-
-               if (IS_ENABLED(CONFIG_CMDLINE_EXTEND))
-                       goto out;
-
-               return false;
-       }
-out:
-       return cmdline_contains_nokaslr(CONFIG_CMDLINE);
-}
+struct arm64_ftr_override kaslr_feature_override __initdata;
 
 /*
  * This routine will be executed with the kernel mapped at its default virtual
@@ -126,7 +94,7 @@ u64 __init kaslr_early_init(void)
         * Check if 'nokaslr' appears on the command line, and
         * return 0 if that is the case.
         */
-       if (is_kaslr_disabled_cmdline(fdt)) {
+       if (kaslr_feature_override.val & kaslr_feature_override.mask & 0xf) {
                kaslr_status = KASLR_DISABLED_CMDLINE;
                return 0;
        }
--
Quoted 2 lines

2.29.2

_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

author maintainer
#31 lore raw

Re: [PATCH v5 18/21] arm64: Move "nokaslr" over to the early cpufeature infrastructure

Quoted 71 lines · Ard Biesheuvel
Quoted 19 lines · Marc Zyngier

Given that the early cpufeature infrastructure has borrowed quite a lot of code from the kaslr implementation, let's reimplement the matching of the "nokaslr" option with it.

---
 arch/arm64/kernel/idreg-override.c | 15 +++++++++++++
 arch/arm64/kernel/kaslr.c          | 36 
++----------------------------
 2 files changed, 17 insertions(+), 34 deletions(-)
arch/arm64/kernel/idreg-override.c +0 -0
index cbb8eaa48742..3ccf51b84ba4 100644

arch/arm64/kernel/idreg-override.c static const struct ftr_set_desc mmfr1 __initdata = · line 37

Quoted 7 lines
arch/arm64/kernel/idreg-override.c +3 -0
@@ -31,8 +31,22 @@ static const struct ftr_set_desc mmfr1 __initdata = 
 {
        },
 };
 
+extern struct arm64_ftr_override kaslr_feature_override;
+
+static const struct ftr_set_desc kaslr __initdata = {

This should be __initconst not __initdata (below too)

Quoted 17 lines
arch/arm64/kernel/idreg-override.c +11 -0
+       .name           = "kaslr",
+#ifdef CONFIG_RANDOMIZE_BASE
+       .override       = &kaslr_feature_override,
+#endif
+       .fields         = {
+               { "disabled", 0 },
+               {}
+       },
+};
+
 static const struct ftr_set_desc * const regs[] __initdata = {
        &mmfr1,
+       &kaslr,
 };
 

static const struct {

arch/arm64/kernel/idreg-override.c static const struct { · line 60

Quoted 6 lines
arch/arm64/kernel/idreg-override.c +1 -0
@@ -41,6 +55,7 @@ static const struct {
 } aliases[] __initdata = {
        { "kvm-arm.mode=nvhe",          "id_aa64mmfr1.vh=0" },
        { "kvm-arm.mode=protected",     "id_aa64mmfr1.vh=0" },
+       { "nokaslr",                    "kaslr.disabled=1" },
 };
 

This struct now takes up
- ~100 bytes for the characters themselves (which btw are not emitted into __initdata or __initconst)
- 6x8 bytes for the char pointers
- 6x24 bytes for the RELA relocations that annotate these pointers as quantities that need to be relocated at boot (on a kernel built with KASLR)

I know it's only a drop in the ocean, but in this case, where the struct is statically declared and defined only once, and in the same place, we could easily turn this into

static const struct {
   char alias[24];
   char param[20];
};
Quoted 4 lines

and get rid of all the overhead. The only slightly annoying thing is that the array sizes need to be kept in sync with the largest instance appearing in the array, but this is easy when the struct type is declared in the same place where its only instance is defined.

Fair enough. I personally find the result butt-ugly, but I agree that it certainly saves some memory. Does the following work for you? I can even give symbolic names to the various constants (how generous of me! ;-).

Thanks,

        M.
arch/arm64/kernel/idreg-override.c +10 -10
index d1310438d95c..9e7043bdc808 100644
@@ -14,15 +14,15 @@
 #include <asm/setup.h>
 
 struct ftr_set_desc {
-	const char 			*name;
+	char 				name[20];
 	struct arm64_ftr_override	*override;
 	struct {
-		const char 		*name;
+		char			name[20];
 		u8			shift;
 	} 				fields[];
 };
 
-static const struct ftr_set_desc mmfr1 __initdata = {
+static const struct ftr_set_desc mmfr1 __initconst = {
 	.name		= "id_aa64mmfr1",
 	.override	= &id_aa64mmfr1_override,
 	.fields		= {
@@ -31,7 +31,7 @@ static const struct ftr_set_desc mmfr1 __initdata = {
 	},
 };
 
-static const struct ftr_set_desc pfr1 __initdata = {
+static const struct ftr_set_desc pfr1 __initconst = {
 	.name		= "id_aa64pfr1",
 	.override	= &id_aa64pfr1_override,
 	.fields		= {
@@ -40,7 +40,7 @@ static const struct ftr_set_desc pfr1 __initdata = {
 	},
 };
 
-static const struct ftr_set_desc isar1 __initdata = {
+static const struct ftr_set_desc isar1 __initconst = {
 	.name		= "id_aa64isar1",
 	.override	= &id_aa64isar1_override,
 	.fields		= {
@@ -54,7 +54,7 @@ static const struct ftr_set_desc isar1 __initdata = {
 
 extern struct arm64_ftr_override kaslr_feature_override;
 
-static const struct ftr_set_desc kaslr __initdata = {
+static const struct ftr_set_desc kaslr __initconst = {
 	.name		= "kaslr",
 #ifdef CONFIG_RANDOMIZE_BASE
 	.override	= &kaslr_feature_override,
@@ -65,7 +65,7 @@ static const struct ftr_set_desc kaslr __initdata = {
 	},
 };
 
-static const struct ftr_set_desc * const regs[] __initdata = {
+static const struct ftr_set_desc * const regs[] __initconst = {
 	&mmfr1,
 	&pfr1,
 	&isar1,
@@ -73,9 +73,9 @@ static const struct ftr_set_desc * const regs[] __initdata = {
 };
 
 static const struct {
-	const char	*alias;
-	const char	*feature;
-} aliases[] __initdata = {
+	char	alias[30];
+	char	feature[80];
+} aliases[] __initconst = {
 	{ "kvm-arm.mode=nvhe",		"id_aa64mmfr1.vh=0" },
 	{ "kvm-arm.mode=protected",	"id_aa64mmfr1.vh=0" },
 	{ "arm64.nobti",		"id_aa64pfr1.bt=0" },
Signature · 5 lines
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
#32 lore raw

Re: [PATCH v5 18/21] arm64: Move "nokaslr" over to the early cpufeature infrastructure

Quoted 79 lines · Marc Zyngier
Quoted 72 lines · Ard Biesheuvel
Quoted 20 lines · Marc Zyngier

Given that the early cpufeature infrastructure has borrowed quite a lot of code from the kaslr implementation, let's reimplement the matching of the "nokaslr" option with it.

---
 arch/arm64/kernel/idreg-override.c | 15 +++++++++++++
 arch/arm64/kernel/kaslr.c          | 36
++----------------------------
 2 files changed, 17 insertions(+), 34 deletions(-)
arch/arm64/kernel/idreg-override.c +0 -0
index cbb8eaa48742..3ccf51b84ba4 100644

arch/arm64/kernel/idreg-override.c static const struct ftr_set_desc mmfr1 __initdata = · line 37

Quoted 7 lines
arch/arm64/kernel/idreg-override.c +3 -0
@@ -31,8 +31,22 @@ static const struct ftr_set_desc mmfr1 __initdata =
 {
        },
 };
 
+extern struct arm64_ftr_override kaslr_feature_override;
+
+static const struct ftr_set_desc kaslr __initdata = {

This should be __initconst not __initdata (below too)

Quoted 17 lines
arch/arm64/kernel/idreg-override.c +11 -0
+       .name           = "kaslr",
+#ifdef CONFIG_RANDOMIZE_BASE
+       .override       = &kaslr_feature_override,
+#endif
+       .fields         = {
+               { "disabled", 0 },
+               {}
+       },
+};
+
 static const struct ftr_set_desc * const regs[] __initdata = {
        &mmfr1,
+       &kaslr,
 };
 

static const struct {

arch/arm64/kernel/idreg-override.c static const struct { · line 60

Quoted 6 lines
arch/arm64/kernel/idreg-override.c +1 -0
@@ -41,6 +55,7 @@ static const struct {
 } aliases[] __initdata = {
        { "kvm-arm.mode=nvhe",          "id_aa64mmfr1.vh=0" },
        { "kvm-arm.mode=protected",     "id_aa64mmfr1.vh=0" },
+       { "nokaslr",                    "kaslr.disabled=1" },
 };
 

This struct now takes up
- ~100 bytes for the characters themselves (which btw are not emitted into __initdata or __initconst)
- 6x8 bytes for the char pointers
- 6x24 bytes for the RELA relocations that annotate these pointers as quantities that need to be relocated at boot (on a kernel built with KASLR)

I know it's only a drop in the ocean, but in this case, where the struct is statically declared and defined only once, and in the same place, we could easily turn this into

static const struct {
   char alias[24];
   char param[20];
};
Quoted 4 lines

and get rid of all the overhead. The only slightly annoying thing is that the array sizes need to be kept in sync with the largest instance appearing in the array, but this is easy when the struct type is declared in the same place where its only instance is defined.

Quoted 5 lines

Fair enough. I personally find the result butt-ugly, but I agree that it certainly saves some memory. Does the following work for you? I can even give symbolic names to the various constants (how generous of me! ;-).

To be honest, I was anticipating more of a discussion, but this looks
reasonable to me. Does 'char feature[80];' really need 80 bytes
though?

Quoted 75 lines
arch/arm64/kernel/idreg-override.c +10 -10
index d1310438d95c..9e7043bdc808 100644
@@ -14,15 +14,15 @@
  #include <asm/setup.h>
 
  struct ftr_set_desc {
-       const char                      *name;
+       char                            name[20];
        struct arm64_ftr_override       *override;
        struct {
-               const char              *name;
+               char                    name[20];
                u8                      shift;
        }                               fields[];
  };
 
-static const struct ftr_set_desc mmfr1 __initdata = {
+static const struct ftr_set_desc mmfr1 __initconst = {
        .name           = "id_aa64mmfr1",
        .override       = &id_aa64mmfr1_override,
        .fields         = {
@@ -31,7 +31,7 @@ static const struct ftr_set_desc mmfr1 __initdata = {
        },
  };
 
-static const struct ftr_set_desc pfr1 __initdata = {
+static const struct ftr_set_desc pfr1 __initconst = {
        .name           = "id_aa64pfr1",
        .override       = &id_aa64pfr1_override,
        .fields         = {
@@ -40,7 +40,7 @@ static const struct ftr_set_desc pfr1 __initdata = {
        },
  };
 
-static const struct ftr_set_desc isar1 __initdata = {
+static const struct ftr_set_desc isar1 __initconst = {
        .name           = "id_aa64isar1",
        .override       = &id_aa64isar1_override,
        .fields         = {
@@ -54,7 +54,7 @@ static const struct ftr_set_desc isar1 __initdata = {
 
  extern struct arm64_ftr_override kaslr_feature_override;
 
-static const struct ftr_set_desc kaslr __initdata = {
+static const struct ftr_set_desc kaslr __initconst = {
        .name           = "kaslr",
  #ifdef CONFIG_RANDOMIZE_BASE
        .override       = &kaslr_feature_override,
@@ -65,7 +65,7 @@ static const struct ftr_set_desc kaslr __initdata = {
        },
  };
 
-static const struct ftr_set_desc * const regs[] __initdata = {
+static const struct ftr_set_desc * const regs[] __initconst = {
        &mmfr1,
        &pfr1,
        &isar1,
@@ -73,9 +73,9 @@ static const struct ftr_set_desc * const regs[]
 __initdata = {
  };
 
  static const struct {
-       const char      *alias;
-       const char      *feature;
-} aliases[] __initdata = {
+       char    alias[30];
+       char    feature[80];
+} aliases[] __initconst = {
        { "kvm-arm.mode=nvhe",          "id_aa64mmfr1.vh=0" },
        { "kvm-arm.mode=protected",     "id_aa64mmfr1.vh=0" },
        { "arm64.nobti",                "id_aa64pfr1.bt=0" },
Quoted 2 lines

--
Jazz is not dead. It just smells funny...

_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

author maintainer
#33 lore raw

Re: [PATCH v5 18/21] arm64: Move "nokaslr" over to the early cpufeature infrastructure

Quoted 3 lines · Ard Biesheuvel
Quoted 2 lines · Marc Zyngier

On 2021-01-25 12:54, Ard Biesheuvel wrote:

[...]

Quoted 22 lines
Quoted 22 lines
Quoted 21 lines

This struct now takes up
- ~100 bytes for the characters themselves (which btw are not emitted into __initdata or __initconst)
- 6x8 bytes for the char pointers
- 6x24 bytes for the RELA relocations that annotate these pointers as quantities that need to be relocated at boot (on a kernel built with KASLR)

I know it's only a drop in the ocean, but in this case, where the struct is statically declared and defined only once, and in the same place, we could easily turn this into

static const struct {
   char alias[24];
   char param[20];
};

and get rid of all the overhead. The only slightly annoying thing is that the array sizes need to be kept in sync with the largest instance appearing in the array, but this is easy when the struct type is declared in the same place where its only instance is defined.

Quoted 8 lines
Quoted 5 lines

Fair enough. I personally find the result butt-ugly, but I agree that it certainly saves some memory. Does the following work for you? I can even give symbolic names to the various constants (how generous of me! ;-).

To be honest, I was anticipating more of a discussion, but this looks reasonable to me.

It looked like a reasonable ask: all the strings are completely useless once the kernel has booted, and I'm the first to moan that I can't boot an arm64 kernel with less than 60MB of RAM (OK, it's a pretty bloated kernel...).

Quoted 1 line

Does 'char feature[80];' really need 80 bytes though?

It really needs 75 bytes, because of this:

	{ "arm64.nopauth",
	  "id_aa64isar1.gpi=0 id_aa64isar1.gpa=0 "
	  "id_aa64isar1.api=0 id_aa64isar1.apa=0"	   },

80 is a round enough number.

Thanks,

        M.
Signature · 5 lines
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
#34 lore raw

Re: [PATCH v5 18/21] arm64: Move "nokaslr" over to the early cpufeature infrastructure

Quoted 46 lines · Marc Zyngier
Quoted 3 lines · Ard Biesheuvel
Quoted 2 lines · Marc Zyngier

On 2021-01-25 12:54, Ard Biesheuvel wrote:

[...]

Quoted 22 lines
Quoted 22 lines
Quoted 21 lines

This struct now takes up
- ~100 bytes for the characters themselves (which btw are not emitted into __initdata or __initconst)
- 6x8 bytes for the char pointers
- 6x24 bytes for the RELA relocations that annotate these pointers as quantities that need to be relocated at boot (on a kernel built with KASLR)

I know it's only a drop in the ocean, but in this case, where the struct is statically declared and defined only once, and in the same place, we could easily turn this into

static const struct {
   char alias[24];
   char param[20];
};

and get rid of all the overhead. The only slightly annoying thing is that the array sizes need to be kept in sync with the largest instance appearing in the array, but this is easy when the struct type is declared in the same place where its only instance is defined.

Quoted 8 lines
Quoted 5 lines

Fair enough. I personally find the result butt-ugly, but I agree that it certainly saves some memory. Does the following work for you? I can even give symbolic names to the various constants (how generous of me! ;-).

To be honest, I was anticipating more of a discussion, but this looks reasonable to me.

It looked like a reasonable ask: all the strings are completely useless once the kernel has booted, and I'm the first to moan that I can't boot an arm64 kernel with less than 60MB of RAM (OK, it's a pretty bloated kernel...).

Quoted 1 line

Does 'char feature[80];' really need 80 bytes though?

Quoted 8 lines

It really needs 75 bytes, because of this:

        { "arm64.nopauth",
          "id_aa64isar1.gpi=0 id_aa64isar1.gpa=0 "
          "id_aa64isar1.api=0 id_aa64isar1.apa=0"          },

80 is a round enough number.

Fair enough. This will inflate the struct substantially, but at least it's all __initconst data now, and it's all NUL bytes so it compresses much better than the pointers and RELA entries.
_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

author maintainer
#35 lore raw

PATCH v5 19/21 arm64: cpufeatures: Allow disabling of BTI from the command-line

In reply to Marc Zyngier

In order to be able to disable BTI at runtime, whether it is for testing purposes, or to work around HW issues, let's add support for overriding the ID_AA64PFR1_EL1.BTI field.

This is further mapped on the arm64.nobti command-line alias.

---
 Documentation/admin-guide/kernel-parameters.txt |  3 +++
 arch/arm64/include/asm/cpufeature.h             |  1 +
 arch/arm64/kernel/cpufeature.c                  |  4 +++-
 arch/arm64/kernel/idreg-override.c              | 11 +++++++++++
 arch/arm64/mm/mmu.c                             |  2 +-
 5 files changed, 19 insertions(+), 2 deletions(-)
Documentation/admin-guide/kernel-parameters.txt +3 -0
index 2786fd39a047..7599fd0f1ad7 100644
@@ -373,6 +373,9 @@
 	arcrimi=	[HW,NET] ARCnet - "RIM I" (entirely mem-mapped) cards
 			Format: <io>,<irq>,<nodeID>
 
+	arm64.nobti	[ARM64] Unconditionally disable Branch Target
+			Identification support
+
 	ataflop=	[HW,M68k]
 
 	atarimouse=	[HW,MOUSE] Atari Mouse
arch/arm64/include/asm/cpufeature.h +1 -0
index b0ed37da4067..4e2f2de9d0d7 100644
@@ -819,6 +819,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;
 
 u32 get_kvm_ipa_limit(void);
 void dump_cpu_features(void);
arch/arm64/kernel/cpufeature.c +3 -1
index c1d6712c4249..bb99ddb212b5 100644
@@ -558,6 +558,7 @@ static const struct arm64_ftr_bits ftr_raz[] = {
 #define ARM64_FTR_REG(id, table) ARM64_FTR_REG_OVERRIDE(id, table, &no_override)
 
 struct arm64_ftr_override id_aa64mmfr1_override;
+struct arm64_ftr_override id_aa64pfr1_override;
 
 static const struct __ftr_reg_entry {
 	u32			sys_id;
@@ -593,7 +594,8 @@ static const struct __ftr_reg_entry {
 
 	/* Op1 = 0, CRn = 0, CRm = 4 */
 	ARM64_FTR_REG(SYS_ID_AA64PFR0_EL1, ftr_id_aa64pfr0),
-	ARM64_FTR_REG(SYS_ID_AA64PFR1_EL1, ftr_id_aa64pfr1),
+	ARM64_FTR_REG_OVERRIDE(SYS_ID_AA64PFR1_EL1, ftr_id_aa64pfr1,
+			       &id_aa64pfr1_override),
 	ARM64_FTR_REG(SYS_ID_AA64ZFR0_EL1, ftr_id_aa64zfr0),
 
 	/* Op1 = 0, CRn = 0, CRm = 5 */
arch/arm64/kernel/idreg-override.c +11 -0
index 3ccf51b84ba4..71349b644246 100644
@@ -31,6 +31,15 @@ static const struct ftr_set_desc mmfr1 __initdata = {
 	},
 };
 
+static const struct ftr_set_desc pfr1 __initdata = {
+	.name		= "id_aa64pfr1",
+	.override	= &id_aa64pfr1_override,
+	.fields		= {
+	        { "bt", ID_AA64PFR1_BT_SHIFT },
+		{}
+	},
+};
+
 extern struct arm64_ftr_override kaslr_feature_override;
 
 static const struct ftr_set_desc kaslr __initdata = {
@@ -46,6 +55,7 @@ static const struct ftr_set_desc kaslr __initdata = {
 
 static const struct ftr_set_desc * const regs[] __initdata = {
 	&mmfr1,
+	&pfr1,
 	&kaslr,
 };
 
@@ -55,6 +65,7 @@ static const struct {
 } aliases[] __initdata = {
 	{ "kvm-arm.mode=nvhe",		"id_aa64mmfr1.vh=0" },
 	{ "kvm-arm.mode=protected",	"id_aa64mmfr1.vh=0" },
+	{ "arm64.nobti",		"id_aa64pfr1.bt=0" },
 	{ "nokaslr",			"kaslr.disabled=1" },
 };
 
arch/arm64/mm/mmu.c +1 -1
index ae0c3d023824..617e704c980b 100644
@@ -628,7 +628,7 @@ static bool arm64_early_this_cpu_has_bti(void)
 	if (!IS_ENABLED(CONFIG_ARM64_BTI_KERNEL))
 		return false;
 
-	pfr1 = read_sysreg_s(SYS_ID_AA64PFR1_EL1);
+	pfr1 = __read_sysreg_by_encoding(SYS_ID_AA64PFR1_EL1);
 	return cpuid_feature_extract_unsigned_field(pfr1,
 						    ID_AA64PFR1_BT_SHIFT);
 }
Signature · 6 lines
2.29.2

_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
author maintainer
#36 lore raw

PATCH v5 20/21 arm64: Defer enabling pointer authentication on boot core

In reply to Marc Zyngier

From: Srinivas Ramana <[email protected]>

Defer enabling pointer authentication on boot core until after its required to be enabled by cpufeature framework. This will help in controlling the feature dynamically with a boot parameter.

---
 arch/arm64/include/asm/pointer_auth.h   | 10 ++++++++++
 arch/arm64/include/asm/stackprotector.h |  1 +
 arch/arm64/kernel/head.S                |  4 ----
 3 files changed, 11 insertions(+), 4 deletions(-)
arch/arm64/include/asm/pointer_auth.h +10 -0
index c6b4f0603024..b112a11e9302 100644
@@ -76,6 +76,15 @@ static inline unsigned long ptrauth_strip_insn_pac(unsigned long ptr)
 	return ptrauth_clear_pac(ptr);
 }
 
+static __always_inline void ptrauth_enable(void)
+{
+	if (!system_supports_address_auth())
+		return;
+	sysreg_clear_set(sctlr_el1, 0, (SCTLR_ELx_ENIA | SCTLR_ELx_ENIB |
+					SCTLR_ELx_ENDA | SCTLR_ELx_ENDB));
+	isb();
+}
+
 #define ptrauth_thread_init_user(tsk)					\
 	ptrauth_keys_init_user(&(tsk)->thread.keys_user)
 #define ptrauth_thread_init_kernel(tsk)					\
@@ -84,6 +93,7 @@ static inline unsigned long ptrauth_strip_insn_pac(unsigned long ptr)
 	ptrauth_keys_switch_kernel(&(tsk)->thread.keys_kernel)
 
 #else /* CONFIG_ARM64_PTR_AUTH */
+#define ptrauth_enable()
 #define ptrauth_prctl_reset_keys(tsk, arg)	(-EINVAL)
 #define ptrauth_strip_insn_pac(lr)	(lr)
 #define ptrauth_thread_init_user(tsk)
arch/arm64/include/asm/stackprotector.h +1 -0
index 7263e0bac680..33f1bb453150 100644
@@ -41,6 +41,7 @@ static __always_inline void boot_init_stack_canary(void)
 #endif
 	ptrauth_thread_init_kernel(current);
 	ptrauth_thread_switch_kernel(current);
+	ptrauth_enable();
 }
 
 #endif	/* _ASM_STACKPROTECTOR_H */
arch/arm64/kernel/head.S +0 -4
index 3243e3ae9bd8..2e116ef255e1 100644
@@ -404,10 +404,6 @@ SYM_FUNC_START_LOCAL(__primary_switched)
 	adr_l	x5, init_task
 	msr	sp_el0, x5			// Save thread_info
 
-#ifdef CONFIG_ARM64_PTR_AUTH
-	__ptrauth_keys_init_cpu	x5, x6, x7, x8
-#endif
-
 	adr_l	x8, vectors			// load VBAR_EL1 with virtual
 	msr	vbar_el1, x8			// vector table address
 	isb
Signature · 6 lines
2.29.2

_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
author maintainer
#37 lore raw

PATCH v5 21/21 arm64: cpufeatures: Allow disabling of Pointer Auth from the command-line

In reply to Marc Zyngier

In order to be able to disable Pointer Authentication at runtime, whether it is for testing purposes, or to work around HW issues, let's add support for overriding the ID_AA64ISAR1_EL1.{GPI,GPA,API,APA} fields.

This is further mapped on the arm64.nopauth command-line alias.

---
 Documentation/admin-guide/kernel-parameters.txt |  3 +++
 arch/arm64/include/asm/cpufeature.h             |  1 +
 arch/arm64/kernel/cpufeature.c                  |  4 +++-
 arch/arm64/kernel/idreg-override.c              | 16 ++++++++++++++++
 4 files changed, 23 insertions(+), 1 deletion(-)
Documentation/admin-guide/kernel-parameters.txt +3 -0
index 7599fd0f1ad7..f9cb28a39bd0 100644
@@ -376,6 +376,9 @@
 	arm64.nobti	[ARM64] Unconditionally disable Branch Target
 			Identification support
 
+	arm64.nopauth	[ARM64] Unconditionally disable Pointer Authentication
+			support
+
 	ataflop=	[HW,M68k]
 
 	atarimouse=	[HW,MOUSE] Atari Mouse
arch/arm64/include/asm/cpufeature.h +1 -0
index 4e2f2de9d0d7..ec6311903ad4 100644
@@ -820,6 +820,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_aa64isar1_override;
 
 u32 get_kvm_ipa_limit(void);
 void dump_cpu_features(void);
arch/arm64/kernel/cpufeature.c +3 -1
index bb99ddb212b5..954a2b7e5d45 100644
@@ -559,6 +559,7 @@ static const struct arm64_ftr_bits ftr_raz[] = {
 
 struct arm64_ftr_override id_aa64mmfr1_override;
 struct arm64_ftr_override id_aa64pfr1_override;
+struct arm64_ftr_override id_aa64isar1_override;
 
 static const struct __ftr_reg_entry {
 	u32			sys_id;
@@ -604,7 +605,8 @@ static const struct __ftr_reg_entry {
 
 	/* Op1 = 0, CRn = 0, CRm = 6 */
 	ARM64_FTR_REG(SYS_ID_AA64ISAR0_EL1, ftr_id_aa64isar0),
-	ARM64_FTR_REG(SYS_ID_AA64ISAR1_EL1, ftr_id_aa64isar1),
+	ARM64_FTR_REG_OVERRIDE(SYS_ID_AA64ISAR1_EL1, ftr_id_aa64isar1,
+			       &id_aa64isar1_override),
 
 	/* Op1 = 0, CRn = 0, CRm = 7 */
 	ARM64_FTR_REG(SYS_ID_AA64MMFR0_EL1, ftr_id_aa64mmfr0),
arch/arm64/kernel/idreg-override.c +16 -0
index 71349b644246..d1310438d95c 100644
@@ -40,6 +40,18 @@ static const struct ftr_set_desc pfr1 __initdata = {
 	},
 };
 
+static const struct ftr_set_desc isar1 __initdata = {
+	.name		= "id_aa64isar1",
+	.override	= &id_aa64isar1_override,
+	.fields		= {
+	        { "gpi", ID_AA64ISAR1_GPI_SHIFT },
+	        { "gpa", ID_AA64ISAR1_GPA_SHIFT },
+	        { "api", ID_AA64ISAR1_API_SHIFT },
+	        { "apa", ID_AA64ISAR1_APA_SHIFT },
+		{}
+	},
+};
+
 extern struct arm64_ftr_override kaslr_feature_override;
 
 static const struct ftr_set_desc kaslr __initdata = {
@@ -56,6 +68,7 @@ static const struct ftr_set_desc kaslr __initdata = {
 static const struct ftr_set_desc * const regs[] __initdata = {
 	&mmfr1,
 	&pfr1,
+	&isar1,
 	&kaslr,
 };
 
@@ -66,6 +79,9 @@ static const struct {
 	{ "kvm-arm.mode=nvhe",		"id_aa64mmfr1.vh=0" },
 	{ "kvm-arm.mode=protected",	"id_aa64mmfr1.vh=0" },
 	{ "arm64.nobti",		"id_aa64pfr1.bt=0" },
+	{ "arm64.nopauth",
+	  "id_aa64isar1.gpi=0 id_aa64isar1.gpa=0 "
+	  "id_aa64isar1.api=0 id_aa64isar1.apa=0"	   },
 	{ "nokaslr",			"kaslr.disabled=1" },
 };
 
Signature · 6 lines
2.29.2

_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm