mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: James Clark <james.clark@linaro.org>
To: Will Deacon <will@kernel.org>
Cc: Michael Williams <Michael.Williams@arm.com>,
	Alexandru Elisei <Alexandru.Elisei@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Catalin Marinas <catalin.marinas@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: Thu, 19 Feb 2026 13:51:26 +0000	[thread overview]
Message-ID: <7b692e5c-d376-4023-80e0-76c9d9c0604f@linaro.org> (raw)
In-Reply-To: <aZcIy1Or4c5-i7Tm@willie-the-truck>



On 19/02/2026 12:57 pm, Will Deacon wrote:
> On Thu, Feb 19, 2026 at 12:08:27PM +0000, James Clark wrote:
>> I'm back to drag this up again. So I think all of the above discussion
>> relies on the ordering given by the indirect read needed for the "might
>> ignore a direct write..." part. But it's _might_ ignore a direct write, it's
>> possible for an implementation to not do that, so there are two possible
>> implementations:
>>
>> #1 Where there is an indirect read to give the write ignore outcome
>> #2 Where there is no write ignore outcome so it doesn't require an
>>     indirect read
>>
>> For #2 there's nothing to force the ordering. We're writing to two different
>> registers (PMBPTR_EL1 and PMBLIMITR_EL1) and we have to have the
>> PMBLIMITR_EL1 write come second for the buffer to be considered configured
>> correctly. For example if the old value of PMBPTR_EL1 is higher than the new
>> PMBLIMITR_EL1 and the write to PMBLIMITR_EL1 happens first then it's
>> misconfigured. That's why we think we need the isb() here.
> 
> I thought profiling was disabled in these cases, so why is it
> misconfigured?
> 
> If it is misconfigured, what can go wrong given that we're either stopped
> or pmscr is clear?
> 
> Will

It is stopped in the interrupt handler because PMBSR_EL1.S = 1. But in 
arm_spe_pmu_start(), PMBSR_EL1.S = 0 so it's not stopped. And with 
PMBPTR_EL1 still being set to the value from the last session it could 
be higher than PMBLIMITR_EL1.

PMSCR_EL1 doesn't affect SPEProfilingStopped(), it's only:

   boolean stopped = (PMBSR_EL1.S == '1');

The conditions for when the buffer needs to be configured correctly from 
R24557 are:

   ProfilingBufferEnabled() && !SPEProfilingStopped() &&
     PMBLIMITR_EL1.FM != DISCARD

I think even if PMSCR_EL1 is clear you can still get a buffer management 
error, even if no samples were going to be written into the buffer. It 
just says:

   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.





  reply	other threads:[~2026-02-19 13:51 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-23 16:03 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
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 [this message]
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=7b692e5c-d376-4023-80e0-76c9d9c0604f@linaro.org \
    --to=james.clark@linaro.org \
    --cc=Alexandru.Elisei@arm.com \
    --cc=Anshuman.Khandual@arm.com \
    --cc=Michael.Williams@arm.com \
    --cc=Rob.Herring@arm.com \
    --cc=Robin.Murphy@arm.com \
    --cc=Suzuki.Poulose@arm.com \
    --cc=catalin.marinas@arm.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=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

all inboxes | Powered by JetHome®