[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y+D6afdDp6St079z@sirena.org.uk>
Date: Mon, 6 Feb 2023 13:02:33 +0000
From: Mark Brown <broonie@...nel.org>
To: Marc Zyngier <maz@...nel.org>
Cc: Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>, Oleg Nesterov <oleg@...hat.com>,
James Morse <james.morse@....com>,
Alexandru Elisei <alexandru.elisei@....com>,
Suzuki K Poulose <suzuki.poulose@....com>,
Oliver Upton <oliver.upton@...ux.dev>,
Shuah Khan <shuah@...nel.org>,
Alan Hayward <alan.hayward@....com>,
Luis Machado <luis.machado@....com>,
Szabolcs Nagy <szabolcs.nagy@....com>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
kvmarm@...ts.linux.dev, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH v4 07/21] arm64/sme: Enable host kernel to access ZT0
On Mon, Feb 06, 2023 at 09:31:20AM +0000, Marc Zyngier wrote:
> __check_override assumes that the ID_AA64SMFR0_EL1 value is in x1, and
> I guess that the intent of the code is to reuse value read a few lines
> above. But as the comment says at the beginning of the macro, x1 will
> be clobbered, and the checks always fails.
Yes, it looks like this is a victim of rebasing - I didn't spot the
change to make x1 clobbered when the override checking was refactored.
Thanks for spotting this.
> I presume we're just lucky that sme2_kernel_enable() does the same
> thing unconditionally, which probably means this was only ever tested
> with a VHE kernel (it'd otherwise catch fire).
Yes, I'd not be surprised if I'd never run this in nVHE.
> The easiest fix is just to reload the id register before checking it,
> something like the patch below, compile-tested only.
Reviewed-by: Mark Brown <broonie@...nel.org>
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists