[PATCH] arm64: use sanitized feature registers for conditional ZCR_EL1 and SMCR_EL1 reads

[Mark Brown]

On Thu, Jul 14, 2022 at 07:47:51AM +0100, Marc Zyngier wrote:
> Peter Collingbourne <pcc at google.com> wrote:

> >  	cpuinfo_detect_icache_policy(info);
> >  }
> >  
> 
> This looks wrong to me. With this change, a secondary CPU never
> initialises its own view of reg_{zcr,smcr}. I came up with the
> following patch instead, also updating the cpuinfo_arm64 structure
> when updating the capabilities on secondary CPU boot (on top of
> arm64/boot):

Ugh, clearly I'm not up to speed enough with how all this stuff
bootstraps :/

> From ee8d6a3741229336acedf13aa1304e05ed630ff0 Mon Sep 17 00:00:00 2001
> From: Marc Zyngier <maz at kernel.org>
> Date: Mon, 11 Jul 2022 16:43:36 +0100
> Subject: [PATCH] arm64: Delay initialisation of cpuinfo_arm64::reg_{zcr,smcr}
> 
> Even if we are now able to tell the kernel to avoid exposing SVE/SME
> from the command line, we still have a couple of places where we
> unconditionally access the ZCR_EL1 (resp. SMCR_EL1) registers.
> 
> On systems with broken firmwares, this results in a crash even if
> arm64.nosve (resp. arm64.nosme) was passed on the command-line.
> 
> To avoid this, only update cpuinfo_arm64::reg_{zcr,smcr} once
> we have computed the sanitised version for the corresponding
> feature registers (ID_AA64PFR0 for SVE, and ID_AA64PFR1 for
> SME). This results in some minor refactoring.

FWIW

Reviewed-by: Mark Brown <broonie at kernel.org>

but that's more from a SVE/SME point of view than from an ID register
point of view.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20220714/d034025c/attachment.sig>