Re: [PATCH] arm64/sme: Move storage of reg_smidr to __cpuinfo_store_cpu()

[Marc Zyngier <maz@kernel.org>]

On Mon, 16 Dec 2024 15:07:15 +0000,
Mark Rutland <mark.rutland@arm.com> wrote:
> 
> On Mon, Dec 16, 2024 at 02:31:43PM +0000, Marc Zyngier wrote:
> > On Mon, 16 Dec 2024 12:38:17 +0000,
> > Mark Rutland <mark.rutland@arm.com> wrote:
> > > I think that what we did in commit:
> > > 
> > >    892f7237b3ff ("arm64: Delay initialisation of cpuinfo_arm64::reg_{zcr,smcr}")
> > > 
> > > ... introduces an anti-pattern that'd be nice to avoid. That broke the
> > > existing split of __cpuinfo_store_cpu() and init_cpu_features(), where
> > > the former read the ID regs, and the latter set up the features
> > > *without* altering the copy of the ID regs that was read. i.e.
> > > init_cpu_features() shouldn't write to its info argument at all.
> > > 
> > > I understand that we have to do something as a bodge for broken FW which
> > > traps SME, but I'd much rather we did that within __cpuinfo_store_cpu().
> > 
> > Honestly, I'd rather revert that patch, together with b3000e2133d8
> > ("arm64: Add the arm64.nosme command line option"). I'm getting tired
> > of the FW nonsense, and we are only allowing vendors to ship untested
> > crap.
> > 
> > Furthermore, given the state of SME in the kernel, I don't think this
> > is makes any difference. So maybe this is the right time to reset
> > everything to a sane state.
> 
> Looking again, a revert does look to be the best option.
> 
> We removed reg_zcr and reg_smcr in v6.7 in commits:
> 
>   abef0695f9665c3d ("arm64/sve: Remove ZCR pseudo register from cpufeature code")
>   391208485c3ad50f ("arm64/sve: Remove SMCR pseudo register from cpufeature code")
> 
> As of those commits, ZCR and SCMR no longer matter to
> __cpuinfo_store_cpu(), and only SMIDR_EL1 remains...
> 
> Per ARM DDI 0487 L.a, accesses to SMIDR_EL1 never trap to EL3, so we can
> read that safely as long as ID_AA64PFR1_EL1.SME indicates that SME is
> implemented.
> 
> Which is to say that if we revert the remaining portion of 892f7237b3ff
> and restore the read of SMIDR, that should be good as far back as v6.7,
> which sounds good to me.

Sounds reasonable indeed. I guess *someone* will want it for the
previous kernel versions, but they can have fun with the backport on
their own.

	M.

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