Re: Query regarding ERRATUM_1418040

From: Marc Zyngier <maz@kernel.org>
To: Will Deacon <will@kernel.org>
Cc: Neeraj Upadhyay <neeraju@codeaurora.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: Query regarding ERRATUM_1418040
Date: Wed, 17 Jun 2020 15:29:46 +0100	[thread overview]
Message-ID: <c3dbc9a990c77abf57de76efd03c6db2@kernel.org> (raw)
In-Reply-To: <20200617112542.GB3503@willie-the-truck>

On 2020-06-17 12:25, Will Deacon wrote:
> On Wed, Jun 17, 2020 at 12:19:16PM +0100, Marc Zyngier wrote:
>> On 2020-06-17 09:55, Neeraj Upadhyay wrote:
>> > I have query regarding the errata 1418040 [1]. Here, on kernel exit to
>> > EL0 64 bit mode, will it always enable ARCH_TIMER_USR_VCT_ACCESS_EN;
>> > and override any other erratas, which might require EL0 direct vct
>> > access to be disabled for 64 bit also?
>> 
>> So far, I am not aware of any erratum that would require traps of 
>> CNTVCT_EL0
>> to EL1 when running AArch64 userspace for CPUs that are affected by
>> ARM-1418040. If such an erratum exists, it would have to be handled
>> separately.
>> 
>> > Also, this errata applies
>> > mitigation for all CPUs (on return to 32 bit EL0), even if, not all
>> > cpus are impacted by the errata?
>> 
>> Indeed. There isn't much we can do to avoid it here, unless you want 
>> to read
>> some per-CPU variable that tells you whether the CPU is affected. This 
>> would
>> add to the cost of the mitigation , and isn't an appealing prospect.
> 
> Hmm, but in conjunction with the previous point, doesn't this mean if
> some CPUs are affected by an erratum which requires CNTVCT trapping for
> AArch64 and others are affected by 1418040, then the former won't 
> actually
> be trapped?

Indeed. Having CPUs that require opposite workarounds is one of the many 
fascinating aspects of BL systems... :-/ Does such a system exist today?

> Maybe we should preserve ARCH_TIMER_USR_VCT_ACCESS_EN for AArch64 tasks
> instead of setting it unconditionally?

We'd still need something when switching from an AArch32 task to an 
AArch64 one. I guess we'd either need to re-enable it on entry from a 
32bit task, or implement some sort of per-CPU, per-ISA state to be 
restored on return to userspace.

         M.
-- 
Jazz is not dead. It just smells funny...

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel