[<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
 
