[PATCH] perf: arm_spe: Support heterogeneous ACPI systems
Johnny Fan
johnny.fan at cixtech.com
Thu Oct 15 04:52:54 PDT 2026
On Thu, Oct 15, 2026 at 11:49:24AM +0100, Marc Zyngier wrote:
> This is a bit odd: at the beginning, you are stating that the SPE
> interrupt being 0 is an indication of SPE not being supported. Then
> you check for PMSVer for the same properly. This seems pretty wrong.
>
> It should be possible to build the mask of SPE-enabled CPUs without
> IPI-ing the other CPUs, and only rely on the firmware table.
Agreed. The MADT walk already tells us which CPUs implement SPE, so the
whole PMSVer probing (including the hotplug compensation for CPUs that
were offline at probe time) can go away: the driver already consumes
platform_get_irq_affinity(), so once the mask comes from the GICC
entries it needs no changes at all.
> This "optional" parameter feels very wrong. We now have an
> infrastructure to get a set of affinities for an interrupt (see
> 5324fe21ba9b7 and following patches). What this needs is ACPI to be
> plumbed into this.
>
> Unfortunately, ACPI is awkward and very badly abstracted in this area,
> but that doesn't mean we should make the driver code more bizarre.
>
> Treating SPE and TRBE differently is just as odd, and there is no
> reason to do other than suiting your particular platform.
Also agreed -- the TRBE overflow interrupt has the same per-CPU
semantics in the GICC, so both devices can share one code path: build
the mask of CPUs reporting a non-zero interrupt, and require a single
GSI across that mask. The current hetid check is replaced by the GSI
consistency check.
The part I'm unsure about is how to convey the MADT-derived mask to
platform_get_irq_affinity() for these devices: they are synthesized by
arm_pmu_acpi.c without an fwnode, so neither the of_node path nor the
_CRS-based ACPI path can reach them. Would you rather see the mask
registered with the GIC domain keyed by GSI, with a fallback in
get_irq_affinity() that resolves by IRQ number, or something simpler at
the platform_device level?
Happy to implement whichever shape you prefer.
Thanks,
Johnny
More information about the linux-arm-kernel
mailing list