From: Johnny Fan <johnny.fan@cixtech.com>
To: Marc Zyngier <maz@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
will@kernel.org, mark.rutland@arm.com, 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, fugang.duan@cixtech.com
Subject: Re: [PATCH] perf: arm_spe: Support heterogeneous ACPI systems
Date: Thu, 15 Oct 2026 19:52:54 +0800 [thread overview]
Message-ID: <atC+lsWALy6ueGAB@JohnnyFan> (raw)
In-Reply-To: <86mrsf1bnv.wl-maz@kernel.org>
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
next prev parent reply other threads:[~2026-10-15 11:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-15 6:29 [PATCH] perf: arm_spe: Support heterogeneous ACPI systems Johnny.Fan
2026-10-15 6:42 ` sashiko-bot
2026-10-15 10:49 ` Marc Zyngier
2026-10-15 11:52 ` Johnny Fan [this message]
2026-10-15 15:58 ` Jeremy Linton
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=atC+lsWALy6ueGAB@JohnnyFan \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.