Re: [PATCH] perf: arm_spe: Support heterogeneous ACPI systems

[Leo Yan <leo.yan@arm.com>]

On Thu, Oct 15, 2026 at 11:49:24AM +0100, Marc Zyngier wrote:

[...]

> > The CPUs without SPE are trimmed from the PMU supported CPUs by
> > probing PMSVer on each CPU, both at probe time (for online CPUs) and
> > from the hotplug callback (for CPUs that were offline at probe), as
> > ACPI conveys no affinity information and the PPI otherwise defaults
> > to all possible CPUs.
> 
> 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 SPE driver probes its capabilities on one CPU selected by
smp_call_function_any(), then performs local setup on every CPU in
supported_cpus. It therefore relies on that mask being accurate;
including a CPU without SPE could lead to accesses to unimplemented
SPE system registers.

> > @@ -97,6 +100,20 @@ arm_acpi_register_pmu_device(struct platform_device *pdev, u8 len,
> >  			return gsi ? -ENXIO : 0;
> >  
> >  		this_gsi = parse_gsi(gicc);
> > +
> > +		if (optional) {
> > +			if (!this_gsi)
> > +				continue;
> > +
> > +			if (gsi && gsi != this_gsi) {
> > +				pr_warn("ACPI: %s: CPU%d: inconsistent interrupt %u/%u\n",
> > +					pdev->name, cpu, gsi, this_gsi);
> > +				return -ENXIO;
> > +			}
> > +			gsi = this_gsi;
> > +			continue;
> > +		}
> > +
> 
> 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.

Yes, SPE and TRBE should be consistent.

There is also a grouping question for SPE and TRBE. If all participating
CPUs implement the feature, but have different capabilities, should ACPI
registration create separate platform devices for the compatible CPU
groups? DT can describe separate CPU subsets using PPI partitions [1].

Thanks,
Leo

[1] https://github.com/torvalds/linux/blob/0fcb05b72344f40806cbe810de8872f1698bf053/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml#L139
[2] https://git.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a.git/+/refs/heads/master/fdts/tc-base.dtsi#328