Re: [PATCH] perf: arm_spe: Add barrier before enabling profiling buffer

On Thu, Feb 19, 2026 at 01:51:26PM +0000, James Clark wrote:

On 19/02/2026 12:57 pm, Will Deacon wrote:

quoted

On Thu, Feb 19, 2026 at 12:08:27PM +0000, James Clark wrote:

quoted

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.

... but doesn't that mean that R24557 is a breaking change to the
architecture? The current Arm ARM doesn't appear to require this,
existing software doesn't honour it so why should we hack extra barriers
into Linux?

Will