Received-SPF: pass (google.com: domain of linux-kernel+bounces-86864-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Date: Thu, 29 Feb 2024 14:47:39 +0000
From: Conor Dooley <conor@kernel.org>
To: Charlie Jenkins <charlie@rivosinc.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Jisheng Zhang <jszhang@kernel.org>, Evan Green <evan@rivosinc.com>,
	=?iso-8859-1?Q?Cl=E9ment_L=E9ger?= <cleger@rivosinc.com>,
	Eric Biggers <ebiggers@kernel.org>,
	Elliot Berman <quic_eberman@quicinc.com>,
	Charles Lohr <lohr85@gmail.com>,
	Conor Dooley <conor.dooley@microchip.com>,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 2/2] riscv: Set unaligned access speed at compile time
Message-ID: <20240229-ship-frail-52cd06745fc2@spud>
References: <20240227-disable_misaligned_probe_config-v5-0-b6853846e27a@rivosinc.com>
 <20240227-disable_misaligned_probe_config-v5-2-b6853846e27a@rivosinc.com>
 <20240228-denote-subscribe-9832cddbd307@spud>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="g9ScbAqWRYzLUy4l"
Content-Disposition: inline
In-Reply-To: <20240228-denote-subscribe-9832cddbd307@spud>


--g9ScbAqWRYzLUy4l
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Clement,

On Wed, Feb 28, 2024 at 10:43:20AM +0000, Conor Dooley wrote:
> > @@ -413,7 +411,9 @@ int handle_misaligned_load(struct pt_regs *regs)
> > =20
> >  	perf_sw_event(PERF_COUNT_SW_ALIGNMENT_FAULTS, 1, regs, addr);
> > =20
> > +#ifdef CONFIG_RISCV_PROBE_UNALIGNED_ACCESS
>=20
> if (IS_ENABLED()), no?
> But perhaps more interestingly - why is this being set here at all?
> My understanding of the emulated stuff was that if the in-kernel
> emulation was enabled, it would be used unless the CPU itself supported
> fast accesses.

> I would expect this to be advertised to userspace once
> the system has booted, not set the first time that a cpu emulates an
> access,
> I feel like I need to take a look at how this has been implemented, I
> never really looked too closely at it and how it is enabled does not
> match my expectations.

I did look at this more closely and I understand why this is being done.
In the vast majority of situations I think it is going to work perfectly
fine, since that first access is going to be during the boot time
probing.
=2E
> >  	*this_cpu_ptr(&misaligned_access_speed) =3D RISCV_HWPROBE_MISALIGNED_=
EMULATED;
> > +#endif
> > =20
> >  	if (!unaligned_enabled)
> >  		return -1;

This is in the diff, so I am commenting here. Firstly, why does this
return -1 and not a regular negative errno?

Secondly, this looks pretty suspect to me - if the sysctl is used to
disable the emulation things like hwprobe will still report that access
is emulated if during boot it was enabled.
I think that if this condition is hit, we actually need to change the
per-cpu variable to set the alignment to unsupported, given the
emulation will (at present & if my understanding is correct) only be
enabled when there's not underlying support for unaligned accesses.

Thoughts?

Cheers,
Conor.

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

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

iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZeCY9QAKCRB4tDGHoIJi
0iavAQCKIPyb10Y8b3+7ZYXeg6e+2o/56nXBEM1MzBoN3u1bqgEAgblW8u6KNYrj
CdDilNguaeoiA2W9aHSsGlJRULWc7Qg=
=V4Ha
-----END PGP SIGNATURE-----

--g9ScbAqWRYzLUy4l--