linux-kernel - Re: [PATCH] arm64/fpsimd: Ensure we don't contend a SMCU from idling CPUs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8c625518-7f73-40c9-8c91-3a0b14240003@sirena.org.uk>
Date: Thu, 5 Sep 2024 19:34:41 +0100
From: Mark Brown <broonie@...nel.org>
To: Catalin Marinas <catalin.marinas@....com>
Cc: Will Deacon <will@...nel.org>, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org, Mark Rutland <mark.rutland@....com>
Subject: Re: [PATCH] arm64/fpsimd: Ensure we don't contend a SMCU from idling
 CPUs

On Thu, Sep 05, 2024 at 06:51:30PM +0100, Catalin Marinas wrote:

> OK, so likely the state is already saved, all we need to do here is
> flush the state and SMSTOP. But why would switching to idle be any
> different than switching to a thread that doesn't used SME? It feels
> like we are just trying to optimise a special case only. Could we not
> instead issue an SMSTOP in the context switch code?

On context switch the SMSTOP is issued as part of loading the state for
the task but we only do that when either returning to userspace or it's
a kernel thread with active FPSIMD usage.  The idle thread is a kernel
thread with no FPSIMD usage so we don't touch the state.  If we did the
SMSTOP unconditionally that'd mean that the optimisation where we don't
reload the FP state if we bounce through a kernel thread would be broken
while using SME which doesn't seem ideal, idling really does seem like a
meaningfully special case here.

> Also this looks hypothetical until we have some hardware to test it on,
> see how it would behave with a shared SME unit.

The specific performance impacts will depend on hardware (there'll
likely be some power impact even on things with a single FP unit per
PE) but given that keeping SM and ZA disabled when not in use is a
fairly strong recommendation in the programming model my inclination at
this point would be to program to the advertised model until we have
confirmation that the hardware actually behaves otherwise.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)