On Thu, Feb 19, 2026 at 02:15:22PM +0000, James Clark wrote:

On 19/02/2026 2:03 pm, Will Deacon wrote:

quoted

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

quoted

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

Yes I suppose it is. The current Arm ARM doesn't require it, but R24577 is
in the "known issues" document for the Arm ARM, so it's saying the ARM is
incorrect here and you shouldn't trust what it says.

  Arm Architecture Reference Manual for A-profile architecture: Known
  issues

  This document includes the Known Issues for the following documents:

    Arm Architecture Reference Manual for A-profile architecture
    (DDI0487)

Presumably the fix will make it into the Arm ARM eventually. 

While that document is called "Known issues" it really means "Key
changes since the last ARM ARM". The items in that are not all bug
fixes.

In this case, R24577 is intended to be a relaxation (that's what the "R"
stands for), which breaks existing widely-deployed SW. It fails to meet
the usual acceptability requirements for a relaxation.

IMO this should not have made it into the architecture as-is.

I suppose there is a chance that this could be deleted from the known issues
and not make it into a future Arm ARM. TBH I have no experience or feeling
to say how likely that would be.

Broken changes have made it into the architecture before, and have been
subsequently reverted. In general, we try to avoid that in the first
place.

I will raise this internally within Arm.

Mark.