Re: [PATCH v2 0/5] arm64: arch_timer: Improve errata handling

[Will Deacon]

Hi Marc,

Sorry it took me so long to look at this.

On Fri, May 08, 2026 at 10:41:58AM +0100, Marc Zyngier wrote:
> This is the second version of this series addressing a couple of
> embarrassing bugs in the prolific arm64 timer errata handling
> department. Nothing changed since v1, which didn't get much traction,
> so this is only a rebase.
> 
> Time is hard. Timers are harder. As a consequence, we have plenty of
> broken counter/timer implementations in the wild, and an
> infrastructure to deal with them.
> 
> However, what we have today suffers from a number of issues:
> 
> - if, on an heterogeneous system, affected CPUs are secondaries, we do
>   record their broken state but don't correct anything
> 
> - we always play games with preemption in order to access per-CPU
>   state, irrespective of the presence of broken CPUs
> 
> I hear someone saying "just use a static key to enable the errata and
> be done with it". Good call, except that we need to do that from a
> CPUHP callback, and that's deadlock central. We can't do it later,
> because this could affect the CPU before the workaround is enabled.
> 
> However, not everything is lost if we turn the logic on its head:
> 
> - always start with the mitigations enabled, even if we don't know of
>   any affected CPU
> 
> - once all CPUs have been seen once, and that we still haven't
>   enabled any workaround, disable the mitigations globally.
> 
> With that, a normal kernel boot with all CPUs will quickly switch to
> no mitigation on decent HW. If you're booting with CPUs disabled, this
> will only kick in once you have booted them all.

I think this series is a definite improvement on the existing (broken)
code, but there are two things that jump out at me with the new code:

1. If somebody uses maxcpus= on perfectly working hardware, they will
   run with the overhead of the workaround. I fear this will be
   unpopular (and I sympathise!)... I suppose we could wait for people
   to scream and then add something like a cmdline option to pinky
   promise that the late CPUs are not affected by any timer errata (we
   could presumably refuse to bring them online if they are?).

2. It's a bit grotty that you have to maintain your own mask to track
   which CPUs have booted once. I'd have thought this information should
   exist already, although none of the existing masks I could find do
   quite what you need. One alternative would be to iterate our per-cpu
   'cpu_data' variable or perhaps you could even use the driver's
   existing 'arch_timer_evt' variable?

Will