[PATCH v1 0/2] arm64/sme: Fix SMPRI_EL1 traps for KVM guests

[PATCH v1 0/2] arm64/sme: Fix SMPRI_EL1 traps for KVM guests

[Mark Brown]

When adding support for SME I missed management of traps for SMPRI_EL1
in KVM guests.  This series adds that management, and also updates the
documentation to help avoid such issues in future.

This was noticed due to Vincent Donnefort noticing that qemu has
implemented support for SME virtualisation but not fine grained traps
which was causing problems for qemu in nVHE mode since that already used
fine grained traps with SME, the FGT registers are not implemented and
UNDEF.  As a result of this change VHE will also be affected so a
separate series "KVM: arm: Refuse to enable KVM on systems with SME but
not FGT" has been sent which will ensure we don't run on such systems.

Mark Brown (2):
  arm64: booting: Document our requirements for fine grained traps with
    SME
  KVM: arm64: Trap access to SMPRI_EL1 in VHE mode

 Documentation/arm64/booting.rst |  8 ++++++++
 arch/arm64/kvm/hyp/vhe/switch.c | 24 ++++++++++++++++++++++--
 2 files changed, 30 insertions(+), 2 deletions(-)


base-commit: 9abf2313adc1ca1b6180c508c25f22f9395cc780
-- 
2.30.2


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

[PATCH v1 1/2] arm64: booting: Document our requirements for fine grained traps with SME

[Mark Brown]

With SME we require that fine grained traps on access to TPIDR2_EL0 and
SMPRI_EL1 are disabled but did not document that fact. Add the relevant
register bits.

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

diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst
index 8aefa1001ae5..8c324ad638de 100644
--- a/Documentation/arm64/booting.rst
+++ b/Documentation/arm64/booting.rst
@@ -340,6 +340,14 @@ Before jumping into the kernel, the following conditions must be met:
     - SMCR_EL2.LEN must be initialised to the same value for all CPUs the
       kernel will execute on.
 
+    - HWFGRTR_EL2.nTPIDR2_EL0 (bit 55) must be initialised to 0b01.
+
+    - HWFGWTR_EL2.nTPIDR2_EL0 (bit 55) must be initialised to 0b01.
+
+    - HWFGRTR_EL2.nSMPRI_EL1 (bit 54) must be initialised to 0b01.
+
+    - HWFGWTR_EL2.nSMPRI_EL1 (bit 54) must be initialised to 0b01.
+
   For CPUs with the Scalable Matrix Extension FA64 feature (FEAT_SME_FA64)
 
   - If EL3 is present:
-- 
2.30.2


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

[PATCH v1 2/2] KVM: arm64: Trap access to SMPRI_EL1 in VHE mode

[Mark Brown]

On systems with SME access to the SMPRI_EL1 priority management register is
controlled by the nSMPRI_EL1 fine grained trap. We manage this trap in nVHE
mode but do not do so when in VHE mode, add the required management.

On systems which do not implement priority mapping not enabling this trap
will allow the guest to discover if the host support SME since the register
will be RES0 rather than UNDEF. On systems implementing priority mapping
the register could be used as a side channel by guests.

Fixes: 861262ab8627 ("KVM: arm64: Handle SME host state when running guests")
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
---
 arch/arm64/kvm/hyp/vhe/switch.c | 24 ++++++++++++++++++++++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switch.c
index 7acb87eaa092..cae581e8dd56 100644
--- a/arch/arm64/kvm/hyp/vhe/switch.c
+++ b/arch/arm64/kvm/hyp/vhe/switch.c
@@ -63,10 +63,20 @@ static void __activate_traps(struct kvm_vcpu *vcpu)
 		__activate_traps_fpsimd32(vcpu);
 	}
 
-	if (cpus_have_final_cap(ARM64_SME))
+	if (cpus_have_final_cap(ARM64_SME)) {
 		write_sysreg(read_sysreg(sctlr_el2) & ~SCTLR_ELx_ENTP2,
 			     sctlr_el2);
 
+		/*
+		 * Disable access to SMPRI_EL1 - we don't need to control
+		 * nTPIDR2_EL0 in VHE mode.
+		 */
+		sysreg_clear_set_s(SYS_HFGRTR_EL2, HFGxTR_EL2_nSMPRI_EL1_MASK,
+				   0);
+		sysreg_clear_set_s(SYS_HFGWTR_EL2, HFGxTR_EL2_nSMPRI_EL1_MASK,
+				   0);
+	}
+
 	write_sysreg(val, cpacr_el1);
 
 	write_sysreg(__this_cpu_read(kvm_hyp_vector), vbar_el1);
@@ -88,9 +98,19 @@ static void __deactivate_traps(struct kvm_vcpu *vcpu)
 	 */
 	asm(ALTERNATIVE("nop", "isb", ARM64_WORKAROUND_SPECULATIVE_AT));
 
-	if (cpus_have_final_cap(ARM64_SME))
+	if (cpus_have_final_cap(ARM64_SME)) {
+		/*
+		 * Enable access to SMPRI_EL1 - we don't need to
+		 * control nTPIDR2_EL0 in VHE mode.
+		 */
+		sysreg_clear_set_s(SYS_HFGRTR_EL2, 0,
+				   HFGxTR_EL2_nSMPRI_EL1_MASK);
+		sysreg_clear_set_s(SYS_HFGWTR_EL2, 0,
+				   HFGxTR_EL2_nSMPRI_EL1_MASK);
+
 		write_sysreg(read_sysreg(sctlr_el2) | SCTLR_ELx_ENTP2,
 			     sctlr_el2);
+	}
 
 	write_sysreg(CPACR_EL1_DEFAULT, cpacr_el1);
 
-- 
2.30.2


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

Re: [PATCH v1 0/2] arm64/sme: Fix SMPRI_EL1 traps for KVM guests

[Oliver Upton]

On Thu, Oct 27, 2022 at 10:04:38PM +0100, Mark Brown wrote:
> When adding support for SME I missed management of traps for SMPRI_EL1
> in KVM guests.  This series adds that management, and also updates the
> documentation to help avoid such issues in future.
> 
> This was noticed due to Vincent Donnefort noticing that qemu has
> implemented support for SME virtualisation but not fine grained traps
> which was causing problems for qemu in nVHE mode since that already used
> fine grained traps with SME, the FGT registers are not implemented and
> UNDEF.  As a result of this change VHE will also be affected so a
> separate series "KVM: arm: Refuse to enable KVM on systems with SME but
> not FGT" has been sent which will ensure we don't run on such systems.
> 
> Mark Brown (2):
>   arm64: booting: Document our requirements for fine grained traps with
>     SME
>   KVM: arm64: Trap access to SMPRI_EL1 in VHE mode

For the series:

Reviewed-by: Oliver Upton <oliver.upton@linux.dev>

--
Thanks,
Oliver

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

Re: [PATCH v1 1/2] arm64: booting: Document our requirements for fine grained traps with SME

[Catalin Marinas]

On Thu, Oct 27, 2022 at 10:04:39PM +0100, Mark Brown wrote:
> With SME we require that fine grained traps on access to TPIDR2_EL0 and
> SMPRI_EL1 are disabled but did not document that fact. Add the relevant
> register bits.
> 
> Signed-off-by: Mark Brown <broonie@kernel.org>

Acked-by: Catalin Marinas <catalin.marinas@arm.com>

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

Re: [PATCH v1 2/2] KVM: arm64: Trap access to SMPRI_EL1 in VHE mode

[Marc Zyngier]

On Thu, 27 Oct 2022 22:04:40 +0100,
Mark Brown <broonie@kernel.org> wrote:
> 
> On systems with SME access to the SMPRI_EL1 priority management register is
> controlled by the nSMPRI_EL1 fine grained trap. We manage this trap in nVHE
> mode but do not do so when in VHE mode, add the required management.
> 
> On systems which do not implement priority mapping not enabling this trap
> will allow the guest to discover if the host support SME since the register
> will be RES0 rather than UNDEF. On systems implementing priority mapping
> the register could be used as a side channel by guests.
> 
> Fixes: 861262ab8627 ("KVM: arm64: Handle SME host state when running guests")
> Signed-off-by: Mark Brown <broonie@kernel.org>
> Cc: stable@vger.kernel.org
> ---
>  arch/arm64/kvm/hyp/vhe/switch.c | 24 ++++++++++++++++++++++--
>  1 file changed, 22 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switch.c
> index 7acb87eaa092..cae581e8dd56 100644
> --- a/arch/arm64/kvm/hyp/vhe/switch.c
> +++ b/arch/arm64/kvm/hyp/vhe/switch.c
> @@ -63,10 +63,20 @@ static void __activate_traps(struct kvm_vcpu *vcpu)
>  		__activate_traps_fpsimd32(vcpu);
>  	}
>  
> -	if (cpus_have_final_cap(ARM64_SME))
> +	if (cpus_have_final_cap(ARM64_SME)) {
>  		write_sysreg(read_sysreg(sctlr_el2) & ~SCTLR_ELx_ENTP2,
>  			     sctlr_el2);
>  
> +		/*
> +		 * Disable access to SMPRI_EL1 - we don't need to control
> +		 * nTPIDR2_EL0 in VHE mode.

It really isn't obvious to me why this is the case. The pseudocode
says for a 'MSR TPIDR2_EL0, <Xt>' (DDI0616 A.a p225):

<quote>
elsif PSTATE.EL == EL1 then
	if Halted() && HaveEL(EL3) && EDSCR.SDD == '1' &&
	   boolean IMPLEMENTATION_DEFINED "EL3 trap priority, when SDD == '1'" &&
	   SCR_EL3.EnTP2 == '0' then
		UNDEFINED;
	elsif EL2Enabled() && (!HaveEL(EL3) || SCR_EL3.FGTEn == '1') &&
	   HFGWTR_EL2.nTPIDR2_EL0 == '0' then
		AArch64.SystemAccessTrap(EL2, 0x18);
	elsif HaveEL(EL3) && SCR_EL3.EnTP2 == '0' then
		if Halted() && EDSCR.SDD == '1' then
			UNDEFINED;
		else
			AArch64.SystemAccessTrap(EL3, 0x18);
	else
		TPIDR2_EL0 = X[t, 64];
</quote>

So when running at EL1, and short of clearing nTPIDR2_EL0, EL1 will
have access to TPIDR2_EL0. What prevents that?

The write to SCTLR_EL2.EnTP2 is also pretty dubious, and doesn't
really cover the access to EL0 (think SCTLR_EL1.EnTP2=1 and
HCR_EL2.{E2H,TGE}={1,0}, for example).

	M.

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

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

Re: [PATCH v1 2/2] KVM: arm64: Trap access to SMPRI_EL1 in VHE mode

[Mark Brown]

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

On Mon, Oct 31, 2022 at 09:45:48AM +0000, Marc Zyngier wrote:
> Mark Brown <broonie@kernel.org> wrote:

> > +		/*
> > +		 * Disable access to SMPRI_EL1 - we don't need to control
> > +		 * nTPIDR2_EL0 in VHE mode.

> It really isn't obvious to me why this is the case. The pseudocode
> says for a 'MSR TPIDR2_EL0, <Xt>' (DDI0616 A.a p225):

Yes, I was just discovering that while checking and replying to your
earlier mail about the other series.  I'll respin.

[-- 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