[PATCH] perf: arm_spe: Support heterogeneous ACPI systems

[Jeremy Linton]

Hi,

On 10/15/26 6:52 AM, Johnny Fan wrote:
> 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.

I don't think the GICC is sufficient, you have to consider actual 
heterogeneous machines that have differing SPE implementations with the 
same PMSVer, which mean you have to keep the PPTT hetid check, and set 
the mask based on both it and the GSIV. Then, like DT create multiple 
platform devices. Which is true with the current patch as well, the 
hetid still needs to be there even if you have differing PPI's because 
it could have more than two differing implementations.


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