Thread (48 messages) 48 messages, 4 authors, 8h ago

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

From: Marc Zyngier <maz@kernel.org>
Date: 2026-07-19 08:35:14
Also in: kvm, kvmarm, linux-doc, linux-kselftest, lkml

On Sat, 18 Jul 2026 15:24:20 +0100,
Mark Brown [off-list ref] wrote:
[1  <text/plain; us-ascii (7bit)>]
On Sat, Jul 18, 2026 at 02:30:04PM +0100, Fuad Tabba wrote:
quoted
On Sat, 18 Jul 2026 at 01:35, Mark Brown [off-list ref] wrote:
quoted
quoted
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.
quoted
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.
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help