From: "Johnny.Fan" <johnny.fan@cixtech.com>
To: will@kernel.org, mark.rutland@arm.com
Cc: linux-arm-kernel@lists.infradead.org,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
maz@kernel.org, james.clark@linaro.org, leo.yan@arm.com,
jeremy.linton@arm.com, cix-kernel-upstream@cixtech.com,
bob.zhang@cixtech.com, jie.fu@cixtech.com,
"Johnny.Fan" <Johnny.Fan@cixtech.com>,
Fugang Duan <fugang.duan@cixtech.com>
Subject: [PATCH] perf: arm_spe: Support heterogeneous ACPI systems
Date: Thu, 15 Oct 2026 14:29:08 +0800 [thread overview]
Message-ID: <20261015062908.3565761-1-johnny.fan@cixtech.com> (raw)
From: "Johnny.Fan" <Johnny.Fan@cixtech.com>
The ACPI MADT describes the SPE overflow interrupt on a per-CPU basis
in the GICC structure, where a CPU that does not implement SPE simply
reports 0. Heterogeneous systems therefore only report the interrupt
on the CPUs that implement SPE, but arm_pmu_acpi.c rejects this as a
non-homogeneous mapping and never creates the SPE platform device.
Treat the SPE interrupt as optional when walking the MADT: skip the
GICCs that report 0 and only require that the CPUs which do report it
agree on the number.
Note that the CPUs reporting the interrupt must still share a single
GSI, as the platform device only exposes one IRQ resource. A system
that assigns a different PPI per cluster cannot be described by this
single-device model.
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.
Tested on a CIX sky1 SoC with heterogeneous SPE support.
Signed-off-by: Johnny.Fan <Johnny.Fan@cixtech.com>
Reviewed-by: Fugang Duan <fugang.duan@cixtech.com>
---
drivers/perf/arm_pmu_acpi.c | 34 +++++++++++++++++++++++-------
drivers/perf/arm_spe_pmu.c | 41 ++++++++++++++++++++++++++++++++++---
2 files changed, 65 insertions(+), 10 deletions(-)
diff --git a/drivers/perf/arm_pmu_acpi.c b/drivers/perf/arm_pmu_acpi.c
index ca6bf8f86cfe..4ece1070827b 100644
--- a/drivers/perf/arm_pmu_acpi.c
+++ b/drivers/perf/arm_pmu_acpi.c
@@ -70,7 +70,8 @@ static void arm_pmu_acpi_unregister_irq(int cpu)
static int __maybe_unused
arm_acpi_register_pmu_device(struct platform_device *pdev, u8 len,
- u16 (*parse_gsi)(struct acpi_madt_generic_interrupt *))
+ u16 (*parse_gsi)(struct acpi_madt_generic_interrupt *),
+ bool optional)
{
int cpu, this_hetid, hetid, irq, ret;
u16 this_gsi = 0, gsi = 0;
@@ -87,7 +88,9 @@ arm_acpi_register_pmu_device(struct platform_device *pdev, u8 len,
/*
* Sanity check all the GICC tables for the same interrupt
- * number. For now, only support homogeneous ACPI machines.
+ * number. For now, only support homogeneous ACPI machines,
+ * unless the interrupt is optional, in which case a CPU that
+ * does not implement the feature simply reports 0.
*/
for_each_possible_cpu(cpu) {
struct acpi_madt_generic_interrupt *gicc;
@@ -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_hetid = find_acpi_cpu_topology_hetero_id(cpu);
if (!gsi) {
hetid = this_hetid;
@@ -107,7 +124,7 @@ arm_acpi_register_pmu_device(struct platform_device *pdev, u8 len,
}
}
- if (!this_gsi)
+ if (!gsi)
return 0;
irq = acpi_register_gsi(NULL, gsi, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_HIGH);
@@ -146,13 +163,16 @@ static u16 arm_spe_parse_gsi(struct acpi_madt_generic_interrupt *gicc)
/*
* For lack of a better place, hook the normal PMU MADT walk
- * and create a SPE device if we detect a recent MADT with
- * a homogeneous PPI mapping.
+ * and create a SPE device if we detect a recent MADT with a PPI
+ * mapping. The SPE overflow interrupt is described per CPU, so a
+ * GICC reporting 0 simply means that the CPU does not implement
+ * SPE; the arm_spe_pmu driver trims such CPUs from its supported
+ * CPUs using PMSVer.
*/
static void arm_spe_acpi_register_device(void)
{
int ret = arm_acpi_register_pmu_device(&spe_dev, ACPI_MADT_GICC_SPE,
- arm_spe_parse_gsi);
+ arm_spe_parse_gsi, true);
if (ret)
pr_warn("ACPI: SPE: Unable to register device\n");
}
@@ -185,7 +205,7 @@ static u16 arm_trbe_parse_gsi(struct acpi_madt_generic_interrupt *gicc)
static void arm_trbe_acpi_register_device(void)
{
int ret = arm_acpi_register_pmu_device(&trbe_dev, ACPI_MADT_GICC_TRBE,
- arm_trbe_parse_gsi);
+ arm_trbe_parse_gsi, false);
if (ret)
pr_warn("ACPI: TRBE: Unable to register device\n");
}
diff --git a/drivers/perf/arm_spe_pmu.c b/drivers/perf/arm_spe_pmu.c
index b70f3fedf028..6f1bacc78b1c 100644
--- a/drivers/perf/arm_spe_pmu.c
+++ b/drivers/perf/arm_spe_pmu.c
@@ -1102,6 +1102,21 @@ static void arm_spe_pmu_perf_destroy(struct arm_spe_pmu *spe_pmu)
perf_pmu_unregister(&spe_pmu->pmu);
}
+static unsigned int arm_spe_pmu_pmsver(void)
+{
+ return cpuid_feature_extract_unsigned_field(read_cpuid(ID_AA64DFR0_EL1),
+ ID_AA64DFR0_EL1_PMSVer_SHIFT);
+}
+
+static void __arm_spe_pmu_trim_supported_cpus(void *info)
+{
+ struct arm_spe_pmu *spe_pmu = info;
+
+ if (!arm_spe_pmu_pmsver())
+ cpumask_clear_cpu(smp_processor_id(),
+ &spe_pmu->supported_cpus);
+}
+
static void __arm_spe_pmu_dev_probe(void *info)
{
int fld;
@@ -1109,8 +1124,7 @@ static void __arm_spe_pmu_dev_probe(void *info)
struct arm_spe_pmu *spe_pmu = info;
struct device *dev = &spe_pmu->pdev->dev;
- fld = cpuid_feature_extract_unsigned_field(read_cpuid(ID_AA64DFR0_EL1),
- ID_AA64DFR0_EL1_PMSVer_SHIFT);
+ fld = arm_spe_pmu_pmsver();
if (!fld) {
dev_err(dev,
"unsupported ID_AA64DFR0_EL1.PMSVer [%d] on CPU %d\n",
@@ -1275,6 +1289,12 @@ static int arm_spe_pmu_cpu_startup(unsigned int cpu, struct hlist_node *node)
if (!cpumask_test_cpu(cpu, &spe_pmu->supported_cpus))
return 0;
+ /* The CPU was offline during probe; trim it if it lacks SPE */
+ if (!arm_spe_pmu_pmsver()) {
+ cpumask_clear_cpu(cpu, &spe_pmu->supported_cpus);
+ return 0;
+ }
+
__arm_spe_pmu_setup_one(spe_pmu);
return 0;
}
@@ -1331,7 +1351,7 @@ static int arm_spe_pmu_irq_probe(struct arm_spe_pmu *spe_pmu)
{
struct platform_device *pdev = spe_pmu->pdev;
const struct cpumask *affinity;
- int irq;
+ int cpu, irq;
irq = platform_get_irq_affinity(pdev, 0, &affinity);
if (irq < 0)
@@ -1344,6 +1364,21 @@ static int arm_spe_pmu_irq_probe(struct arm_spe_pmu *spe_pmu)
cpumask_copy(&spe_pmu->supported_cpus, affinity);
+ /*
+ * Heterogeneous systems may only implement SPE on a subset of the
+ * CPUs covered by the interrupt affinity (ACPI in particular has
+ * no affinity information and falls back to cpu_possible_mask).
+ * SPE is self-describing through PMSVer, so drop the online CPUs
+ * that do not implement it. CPUs that are offline at probe time
+ * are checked when they come up.
+ */
+ for_each_cpu(cpu, &spe_pmu->supported_cpus) {
+ if (cpu_online(cpu))
+ smp_call_function_single(cpu,
+ __arm_spe_pmu_trim_supported_cpus,
+ spe_pmu, 1);
+ }
+
spe_pmu->irq = irq;
return 0;
}
--
2.55.0
next reply other threads:[~2026-10-15 6:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-15 6:29 Johnny.Fan [this message]
2026-10-15 10:49 ` [PATCH] perf: arm_spe: Support heterogeneous ACPI systems Marc Zyngier
2026-10-15 11:52 ` Johnny Fan
2026-10-15 14:19 ` Leo Yan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261015062908.3565761-1-johnny.fan@cixtech.com \
--to=johnny.fan@cixtech.com \
--cc=bob.zhang@cixtech.com \
--cc=cix-kernel-upstream@cixtech.com \
--cc=fugang.duan@cixtech.com \
--cc=james.clark@linaro.org \
--cc=jeremy.linton@arm.com \
--cc=jie.fu@cixtech.com \
--cc=leo.yan@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox