On Thu, 24 Feb 2022 18:26:41 +0000, Mark Rutland <mark.rutland@xxxxxxx> wrote: > > On Thu, Feb 24, 2022 at 10:07:34PM +0900, Hector Martin wrote: > > Hi folks, > > Hi Hector, > > > In the t6000/t6001 (M1 Pro / Max) SoCs, Apple introduced a new version > > of their interrupt controller. This is a significant departure from > > AICv1 and seems designed to better scale to larger chips. This series > > adds support for it to the existing AIC driver. > > > > Gone are CPU affinities; instead there seems to be some kind of > > "automagic" dispatch to willing CPU cores, and cores can also opt-out > > via an IMP-DEF sysreg (!). Right now the bootloader just sets up all > > cores to accept IRQs, and we ignore all this and let the magic > > algorithm pick a CPU to accept the IRQ. > > Maybe that's ok for the set of peripherals attached, but in general that > violates existing expectations regarding affinity, and I fear there'll > be some subtle brokenness resulting from this automatic target > selection. > > For example, in the perf events subsystem there are PMU drivers (even > those for "uncore" or "system" devices which are shared by many/all > CPUs) which rely on a combination of interrupt affinity and local IRQ > masking (without any other locking) to provide exclusion between a PMU's > IRQ handler and any other management operations for that PMU (which are > all handled from the same CPU). It will definitely break anything that relies on managed interrupts, where the kernel expects to allocate interrupts that have a strict affinity. Drivers using this feature can legitimately expect that they can keep their state in per-CPU pointers, and that obviously breaks. This may affect any PCIe device with more than a couple of queues. Maybe users of this HW do not care (yet), but we'll have to find a way to tell drivers of the limitation. M. -- Without deviation from the norm, progress is not possible.
