From: Will Deacon <will@kernel.org>
To: James Clark <james.clark@linaro.org>
Cc: Leo Yan <leo.yan@arm.com>, 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: Tue, 3 Feb 2026 09:32:49 +0000 [thread overview]
Message-ID: <aYHAwakKuoXturtV@willie-the-truck> (raw)
In-Reply-To: <95e205af-3dec-48c7-8a0d-293629f1551b@linaro.org>
On Tue, Feb 03, 2026 at 09:29:56AM +0000, James Clark wrote:
>
>
> On 02/02/2026 7:14 pm, Leo Yan wrote:
> > On Mon, Feb 02, 2026 at 06:57:11PM +0000, Will Deacon wrote:
> >
> > [...]
> >
> >
> > > > > 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."
> > >
> > > Hmm, so let's say we've executed the first ISB. At that point, the
> > > Profiling Buffer is disabled (PMBLIMITR_EL1.E = 0) and profiling is
> > > stopped (PMBSR_EL1.S = 1).
> >
> > This is not true. PMBLIMITR_EL1.E is always 1 during interrupt
> > handling.
Ah, yes, thank you for correcting me here.
> > > If we *don't* have the second ISB then either
> > > PMBLIMITR_EL1 is written first or PMBSR_EL1 is written first. But the
> > > text you quoted will only come into effect once they've both happened,
> > > right? In which case, why does the order matter for the success case?
> >
> > Yes, both PMBLIMITR_EL1.E == 1 and PMBSR_EL1.S == 0 must be true to
> > enable tracing.
> >
> > However, the tricky part is that PMBLIMITR_EL1.E remains 1 throughout
> > the sequence. Writing PMBLIMITR_EL1 effectively only sets the limit,
> > while clearing PMBSR_EL1 is the distinct step that enables tracing.
> >
> > Thanks,
> > Leo
>
> I think Leo is correct that the old isb() is still needed. I removed it
> under the assumption that PMBLIMITR_EL1.E was unset in the interrupt
> handler. Possibly because the previous version re-arranged the handler to do
> that.
>
> If PMBLIMITR_EL1.E is set, we have to make sure clearing PMBSR_EL1 comes
> last as it's the thing that defines the point where both pointers must be
> correct by.
Agreed that we can't remove the existing isb, but please see my other
reply as I'm not entirely sure we need to add an extra isb to handle the
arch relaxation.
Will
next prev parent reply other threads:[~2026-02-03 9:33 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
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 [this message]
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=aYHAwakKuoXturtV@willie-the-truck \
--to=will@kernel.org \
--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=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 \
/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