From: Will Deacon <will@kernel.org>
To: James Clark <james.clark@linaro.org>
Cc: 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>, Leo Yan <leo.yan@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 19:03:13 +0000 [thread overview]
Message-ID: <aYD08d42SewAAQCB@willie-the-truck> (raw)
In-Reply-To: <20260123-james-spe-relaxation-v1-1-4ccb88fa7bc5@linaro.org>
On Fri, Jan 23, 2026 at 04:03:53PM +0000, James Clark wrote:
> The Arm ARM known issues document [1] states that the architecture will
> be relaxed so that the profiling buffer must be correctly configured
> when ProfilingBufferEnabled() && !SPEProfilingStopped() &&
> PMBLIMITR_EL1.FM != DISCARD:
>
> R24557
>
> 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.
>
> The same relaxation also says that writes may be completely ignored:
>
> When the Profiling Buffer is enabled, profiling is not stopped, and
> Discard mode is not enabled, the PE might ignore a direct write to any
> of the following Profiling Buffer registers, other than a direct write
> to PMBLIMITR_EL1 that clears PMBLIMITR_EL1.E from 1 to 0:
>
> * The current write pointer, PMBPTR_EL1.
> * The Limit pointer, PMBLIMITR_EL1.
> * PMBSR_EL1.
Thinking about this some more, does that mean that the direct write to
PMBPTR_EL1 performs an indirect read of PMBLIMITR_EL1 so that it can
determine the write-ignore semantics? If so, doesn't that mean that
we'll get order against a subsequent direct write of PMBLIMITR_EL1
without an ISB thanks to table "D24-1 Synchronization requirements"
which says that an indirect read followed by a direct write doesn't
require synchronisation?
There's also a sentence above the table stating:
"Direct writes to System registers are not allowed to affect any
instructions appearing in program order before the direct write."
so after all that, I'm not really sure why the ISB is required.
Will
next prev parent reply other threads:[~2026-02-02 19:03 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
2026-02-02 19:03 ` Will Deacon [this message]
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=aYD08d42SewAAQCB@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