Received-SPF: pass (google.com: domain of linux-kernel+bounces-44623-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Tue, 30 Jan 2024 12:42:13 +0000
From: Mark Brown <broonie@kernel.org>
To: Dave Martin <Dave.Martin@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Jackson Cooper-Driver <Jackson.Cooper-Driver@arm.com>,
	linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] arm64/sme: Restore SMCR on exit from suspend
Message-ID: <65973ce3-a316-40a4-bad4-fbc99bccff12@sirena.org.uk>
References: <20240130-arm64-sme-resume-v1-0-0e60ebba18df@kernel.org>
 <20240130-arm64-sme-resume-v1-1-0e60ebba18df@kernel.org>
 <ZbjVNggOxxoQXitV@e133380.arm.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="k0mhTPwGrUaa4/vP"
Content-Disposition: inline
In-Reply-To: <ZbjVNggOxxoQXitV@e133380.arm.com>


--k0mhTPwGrUaa4/vP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Tue, Jan 30, 2024 at 10:53:42AM +0000, Dave Martin wrote:
> On Tue, Jan 30, 2024 at 12:02:48AM +0000, Mark Brown wrote:

Sorry, didn't see these bits due to the large block of quoted text.

> > +	if (system_supports_fa64())
> > +		smcr |= SMCR_ELx_FA64;

> This seems to silently duplicate logic present in cpufeatures.c.
> Would it be cleaner to save/restore this register explicitly across
> suspend, once cpufeatures has initialised it?

I was unsure about that, I could go either way.  All the register save
and restore is currently done in assembler which felt like it was doing
things too early so I went with this instead.

> Or this could be factored somehow, but dumbly saving/restoring it is
> probably simpler (?)

Yes, I keep thinking about doing that but factoring out is annoying
since there's also the KVM case where we don't always want to base the
decision about the settings on the cpufeature detection.

> > +	write_sysreg_s(smcr, SYS_SMCR_EL1);

> Is there an ISB or equivalent somewhere on this path?

> Can we blow up when trying to restore SME state (e.g., ZT0) before we
> enter userspace for the first time, if the firmware left the SME regs
> inaccessible?

I concluded when I wrote this that there was but I confess I can't
remember where exactly now.

--k0mhTPwGrUaa4/vP
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmW47qQACgkQJNaLcl1U
h9DwhAf9EzbjO8QDLngdgs/w1U8tbbLzYccixDancPw6pIBneMEiM2dV8XYztDob
QiRsSxX4UXsGBCJJH/RhI1jFcWVOVS3XilPcDaci7If2OGMHfhafi5DFUmFSE24z
XFgNxZvDs81+CyBvMI+AKb2sXIN5YnxbKRQFcII8sJA0HgmJI46XlLo+XTXOsliq
+R2QuphM+6bmkWynrD5lQfVloSz8VGk4jQBott06irR1Aan/Yh0Kat8XaGNZOuFx
75a7WKfDkx0OGJe7tOvNHGfq3okG71/oZGzOYdACF0GkpRkRb/8ZzGM9pvkvjN8b
X0bqQlvC/heUdIVctGsrjHf9a0vk5Q==
=Mb4u
-----END PGP SIGNATURE-----

--k0mhTPwGrUaa4/vP--