From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F1E3C4A68A4; Thu, 15 Oct 2026 10:49:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792061368; cv=none; b=eXmCEjptSdV8jhYp0NI/33JKEbgYNwgjP+TOyN0PWIy0BUErJH24BrOZaJC6TbJCT6S1tiJXnnYZW9aNDFrRnXc3/Il1vxRw0T9fZPvqrSAzJRqRG1+NnZPzvh84ODzmwxIoEu2O8RfaLlyfNyhsT8o4X1gF3/fLoMF3gKxgGOM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792061368; c=relaxed/simple; bh=M2aLTKL4TVzR/0wELrO8Jzd79cG96V1GTXib1AxvoWs=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=Dc6/4FtG/fu+cty1iakf6rvlAEW3rJiAlWpMBh29nQiRqTrz+ZUdGuHqSE9vc1Cfbjx0P/IRjN6F335B2YoImsai7H2doeszjMF7BmvwUIw1YD8N2wEUnA52LNCEDTxl9jN/n3Gj6v2kICq9ho/VM4baTqsttkoG6S/rYohmxOs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=gN6L7L5g; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="gN6L7L5g" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D7C4D1F000C4; Thu, 15 Oct 2026 10:49:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792061366; bh=eS5dgKRrqB5G6xJ5ae/At6FZ/Fbw4j2g/klkldfI5mg=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=gN6L7L5gFoctGU9ho+DbAeF1+o7pakdSBsfk1oFhs1RO8TZTYf5TZvaylaBgDj041 koJVxR33c6hXhI7EjtG/zY+KGOnE9GDDyI0flrc3MPev+f/R6T6d4PnxIBXZoBzsS6 rteD4tUdeYGqZeGN+aVjM3R0zHxaFiQb3VP8owujSHhTKlMDlNnT0eNH7MBsBSVDMR Gx5000xkq8AGiE5EboSz/fcPeWV9sZbOra8dbn9jX8z7X1zHvSKoGJlq500i5nLFqc 7/x87dbIR61vizFKHDxQpOLyZFkqg7486FIBrZsSoMCE/Zh3gpo3yg8KjVrvv9RyeA MfIcNZ6fei3sw== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1xHJ1Y-00000003G8o-38kc; Thu, 15 Oct 2026 10:49:24 +0000 Date: Thu, 15 Oct 2026 11:49:24 +0100 Message-ID: <86mrsf1bnv.wl-maz@kernel.org> From: Marc Zyngier To: "Johnny.Fan" Cc: will@kernel.org, mark.rutland@arm.com, linux-arm-kernel@lists.infradead.org, linux-perf-users@vger.kernel.org, linux-kernel@vger.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" , Fugang Duan Subject: Re: [PATCH] perf: arm_spe: Support heterogeneous ACPI systems In-Reply-To: <20261015062908.3565761-1-johnny.fan@cixtech.com> References: <20261015062908.3565761-1-johnny.fan@cixtech.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: linux-perf-users@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: johnny.fan@cixtech.com, will@kernel.org, mark.rutland@arm.com, linux-arm-kernel@lists.infradead.org, linux-perf-users@vger.kernel.org, linux-kernel@vger.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@cixtech.com, fugang.duan@cixtech.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Thu, 15 Oct 2026 07:29:08 +0100, "Johnny.Fan" wrote: > > From: "Johnny.Fan" > > 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. 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. > > Tested on a CIX sky1 SoC with heterogeneous SPE support. > > Signed-off-by: Johnny.Fan > > Reviewed-by: Fugang Duan > --- > 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 "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. Thanks, M. -- Without deviation from the norm, progress is not possible.