Re: [PATCH v12 02/29] arm64/fpsimd: Update FA64 and ZT0 enables when loading SME state

[Marc Zyngier]

On Sat, 18 Jul 2026 15:24:20 +0100,
Mark Brown <broonie@xxxxxxxxxx> wrote:
> 
> [1  <text/plain; us-ascii (7bit)>]
> On Sat, Jul 18, 2026 at 02:30:04PM +0100, Fuad Tabba wrote:
> > On Sat, 18 Jul 2026 at 01:35, Mark Brown <broonie@xxxxxxxxxx> wrote:
> 
> > > Actually I remembered: while SCMR_EL1.LEN is self synchronising the
> > > "without the need for explict synchronization" wording is not present
> > > for SMCR_EL1.{FA64,EZT0} and this is no longer explicitly just an update
> > > of LEN.  It's possible I'm being overly paranoid here, I'll leave the
> > > isb() and add a comment for the next version.
> 
> > I went through the ARM ARM (DDI 0487 M.c) on this and I don't think
> > you're being overly paranoid, I believe the isb() is needed here.
> 
> Thanks for double checking so thoroughly.
> 
> > And task_fpsimd_load() does make indirect reads of both fields before
> > the next context synchronization event: sme_load_state() executes LDR
> > ZT0, whose execution at EL1 is trapped when SMCR_EL1.EZT0 is 0, and
> > when PSTATE.SM is set sve_load_state() executes WRFFR, which is
> > "illegal when executed in Streaming SVE mode, unless FEAT_SME_FA64 is
> > implemented and enabled" (from the WRFFR description). The MSR SVCR in
> > between doesn't provide the synchronization, since SVCR's
> > self-synchronisation wording covers reads of its own SM and ZA fields
> > only.
> 
> Yeah.  We should be able to optimise this:
> 
>  - If there is no change we don't need the isb().
>  - If only EZT0 changes and we load state where ZA is disabled then we
>    won't try to access ZT0.
>  - If only FA64 changes and we load state where streaming mode is
>    disabled then we won't try to access streaming mode FFR.
> 
> I've gone and implemented the first which will suppress the isb() for
> current host kernel SME usage, the second two are starting to get more
> fiddly than seems sensible to do right now.

I really wish you didn't optimise anything at all at this stage.

"Optimisation" is exactly what got us into so much trouble over the
past two years, and I really don't want SME in KVM to follow the same
trajectory.

So leave this is a straight ISB, no optimisation. Once you come back
with actual data showing that this is a terrible bottleneck affecting
real workloads on real HW, we'll look at it. But until then, please
keep it as stupid as possible.

Thanks,

	M.

-- 
Jazz isn't dead. It just smells funny.