From: Leo Yan <leo.yan@arm.com>
To: Will Deacon <will@kernel.org>
Cc: James Clark <james.clark@linaro.org>,
Mark Rutland <mark.rutland@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Alexandru Elisei <Alexandru.Elisei@arm.com>,
Anshuman Khandual <Anshuman.Khandual@arm.com>,
Rob Herring <Rob.Herring@arm.com>,
Suzuki Poulose <Suzuki.Poulose@arm.com>,
Robin Murphy <Robin.Murphy@arm.com>,
linux-arm-kernel@lists.infradead.org,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] perf: arm_spe: Add barrier before enabling profiling buffer
Date: Mon, 2 Feb 2026 18:42:34 +0000 [thread overview]
Message-ID: <20260202184234.GC3481290@e132581.arm.com> (raw)
In-Reply-To: <aYDWpc8Jh4SqMcD5@willie-the-truck>
On Mon, Feb 02, 2026 at 04:53:57PM +0000, Will Deacon wrote:
[...]
> > > To avoid redundant isb()s in the IRQ handler, remove the isb() between
> > > the PMBLIMITR_EL1 write and SYS_PMBSR_EL1 as it doesn't matter which
> > > order these happen in now that all the previous configuration is covered
> > > by the new isb().
> >
> > The isb() in the interrupt handler is useful and should not be removed.
> >
> > See the sequence in the interrupt handler:
> >
> > arm_spe_perf_aux_output_begin() {
> > write_sysreg_s(base, SYS_PMBPTR_EL1);
> >
> > // Ensure the write pointer is ordered
> > isb();
> >
> > write_sysreg_s(limit, SYS_PMBLIMITR_EL1);
> > }
> >
> > // Ensure the limit pointer is ordered
> > isb();
> >
> > // Profiling is enabled:
> > // (PMBLIMITR_EL1.E==1) && (PMBSR_EL1.S==0) && (not discard mode)
> > write_sysreg_s(0, SYS_PMBSR_EL1);
> >
> > The first isb() ensures that the write pointer update is ordered. The
> > second isb() ensures that the limit pointer is visible before profiling
> > is enabled by clearing the PMBSR_EL1.S bit. When handling a normal
> > maintenance interrupt, PMBSR_EL1.S is set by the SPE to stop tracing,
> > while PMBLIMITR_EL1.E remains set. Clearing PMBSR_EL1.S therefore
> > effectively re-enables profiling.
> >
> > Since the second isb() is a synchronization for both the write pointer
> > and the limit pointer before profiling is enabled, it could be argued
> > that the first isb() is redundant in the interrupt handling. However,
> > the first isb() is crucial for the arm_spe_pmu_start() case, and keeping
> > it in the interrupt handler does no harm and simplifies code maintenance.
> >
> > In short, if preserves the second isb() instead of removing it, the
> > change looks good to me.
>
> I'm not sure I follow your logic as to why both ISBs are required, but
> I'd have thought that if perf_aux_output_begin() fails when called from
> arm_spe_perf_aux_output_begin() in the irqhandler, we need the ISB
> because we're going to clear pmblimitr_el1 to 0 and that surely has
> to be ordered before clearing pmbsr?
I think the ISB after arm_spe_perf_aux_output_begin() in the irq
handler is required for both the failure and success cases.
For a normal maintenance interrupt, an ISB is inserted between writing
PMBLIMITR_EL1 and PMBSR_EL1 to ensure that a valid limit write is
visible before tracing restarts. This ensures that the following
conditions are safely met:
"While the Profiling Buffer is enabled, profiling is not stopped, and
Discard mode is not enabled, all of the following must be true:
The current write pointer must be at least one sample record below
the write limit pointer.
PMBPTR_EL1.PTR[63:56] must equal PMBLIMITR_EL1.LIMIT[63:56],
regardless of the value of the applicable TBI bit."
Thanks,
Leo
next prev parent reply other threads:[~2026-02-02 18:42 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-23 16:03 [PATCH] perf: arm_spe: Add barrier before enabling profiling buffer James Clark
2026-01-30 20:24 ` Leo Yan
2026-02-02 16:53 ` Will Deacon
2026-02-02 18:42 ` Leo Yan [this message]
2026-02-02 18:57 ` Will Deacon
2026-02-02 19:14 ` Leo Yan
2026-02-03 9:29 ` James Clark
2026-02-03 9:32 ` Will Deacon
2026-02-02 19:03 ` Will Deacon
2026-02-03 10:46 ` James Clark
2026-02-03 11:07 ` Will Deacon
2026-02-06 9:50 ` James Clark
2026-02-19 12:08 ` James Clark
2026-02-19 12:57 ` Will Deacon
2026-02-19 13:51 ` James Clark
2026-02-19 14:03 ` Will Deacon
2026-02-19 14:15 ` James Clark
2026-02-19 14:30 ` Mark Rutland
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=20260202184234.GC3481290@e132581.arm.com \
--to=leo.yan@arm.com \
--cc=Alexandru.Elisei@arm.com \
--cc=Anshuman.Khandual@arm.com \
--cc=Rob.Herring@arm.com \
--cc=Robin.Murphy@arm.com \
--cc=Suzuki.Poulose@arm.com \
--cc=catalin.marinas@arm.com \
--cc=james.clark@linaro.org \
--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=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