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

[Mark Brown]

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.

Attachment: signature.asc
Description: PGP signature