Re: [PATCH RESEND v7 00/21] drivers/perf: apple_m1: Add Apple A7-A11, T2 SoC support
From: Mark Rutland <mark.rutland@arm.com>
Date: 2025-07-17 15:05:18
Also in:
asahi, linux-devicetree, linux-perf-users, lkml
On Mon, Jul 14, 2025 at 11:59:36PM +0800, Nick Chan wrote:
Will Deacon 於 2025/7/14 夜晚11:12 寫道:quoted
On Mon, Jun 16, 2025 at 09:31:49AM +0800, Nick Chan wrote:quoted
This series adds support for the CPU PMU in the older Apple A7-A11, T2 SoCs. These PMUs may have a different event layout, less counters, or deliver their interrupts via IRQ instead of a FIQ. Since some of those older SoCs support 32-bit EL0, counting for 32-bit EL0 also need to be enabled by the driver where applicable. Patch 1 adds the DT bindings. Patch 2-7 prepares the driver to allow adding support for those older SoCs.Modulo my nits, the patches look alright to this point...quoted
Patch 8-12 adds support for the older SoCs.... but I'm not sure if anybody actually cares about these older SoCs and, even if they do, what the state of the rest of Linux is on those parts. I recall horror stories about the OS being quietly migrated between CPUs with incompatible features, at which point I think we have to question whether we actually care about supporting this hardware.The "horror" story you mentioned is about Apple A10/A10X/T2, which has a big little switcher integrated into the cpufreq block, so when the cpufreq driver switch between states in the same way as on other SoCs, on these SoCs that would silently cause a CPU migration. There is only one incompatible feature that I am aware of which is 32-bit EL0 support.
Surely the MIDR/REVIDR/AIDR also change? In general, silent migration isn't acceptable for the kernel, even if you largely happen to get away with that today. It is not acceptable for architectural feature support to change dynamically.
However, since the CPUs in these SoCs does not support 4K pages anyways in practice this is not an issue for as long as CONFIG_EXPERT is disabled.
Do these parts have EL2?
quoted
On the other hand, if it all works swimmingly and it's just the PMU driver that needs updating, then I could get on board with it.As mentioned above, it does all work fine when CONFIG_EXPERT is not enabled, and if it is enabled, then 32-bit process may crash with illegal instruction but everything else will still works fine.
I don't think that's quite true, unless these parts are also violating the architecture. If the CPU doesn't implement AArch32, then an ERET to AArch32 is illegal. The way illegal exception returns are handled means that this will result in a (fatal) illegal execution state exception being taken from the exception return code in the kernel, not an UNDEF being taken from userspace that would result in a SIGILL. I do not think that we should pretend to support hardware with silent microarchitectural migration. So at the very least, we do not care about A10/A10X/T2. Mark.