Query regarding ERRATUM_1418040

[Will Deacon]

On Wed, Jun 17, 2020 at 03:29:46PM +0100, Marc Zyngier wrote:
> 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?

I don't know, but it feels like we should either address the issue of scream
loudly if we detect it!

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

I think re-enabling on entry from a 32-bit task would be the easiest thing to
do. Since you're playing with 32-bit timer bugs atm, do you fancy taking a
look ;)

Will