From: James Clark <james.clark@linaro.org>
To: Leo Yan <leo.yan@arm.com>
Cc: Will Deacon <will@kernel.org>,
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 2/3] perf: arm_spe: Disable buffer before writing to PMBPTR_EL1 or PMBSR_EL1
Date: Mon, 7 Jul 2025 12:39:57 +0100 [thread overview]
Message-ID: <b77f12e7-ea3f-4c57-9706-ff8e32721cc8@linaro.org> (raw)
In-Reply-To: <20250704155016.GI1039028@e132581.arm.com>
On 04/07/2025 4:50 pm, Leo Yan wrote:
> On Tue, Jul 01, 2025 at 04:31:58PM +0100, James Clark wrote:
>
> [...]
>
>> @@ -661,16 +666,24 @@ static irqreturn_t arm_spe_pmu_irq_handler(int irq, void *dev)
>> */
>> irq_work_run();
>>
>> + /*
>> + * arm_spe_pmu_buf_get_fault_act() already drained, and PMBSR_EL1.S == 1
>> + * means that StatisticalProfilingEnabled() == false. So now we can
>> + * safely disable the buffer.
>> + */
>> + write_sysreg_s(0, SYS_PMBLIMITR_EL1);
>> + isb();
>> +
>> + /* Status can be cleared now that PMBLIMITR_EL1.E == 0 */
>> + write_sysreg_s(0, SYS_PMBSR_EL1);
>> +
>
> An important thing is about sequence:
> As described in arm_spe_pmu_disable_and_drain_local(), should we always
> clear ELs bits in PMSCR_EL1 before clear PMBLIMITR_EL1.E bit? As a
> reference, we could see TRBE always clear ELx bits before disable trace
> buffer.
>
> And a trivial flaw:
>
> If the TRUNCATED flag has been set, the irq_work_run() above runs the
> IRQ work to invoke the arm_spe_pmu_stop() to disable trace buffer, which
> clear SYS_PMBLIMITR_EL1.E bit. This is why the current code does not
> explictly clear SYS_PMBLIMITR_EL1.E bit.
>
> With this patch, the interrupt handler will clear SYS_PMBLIMITR_EL1.E
> bit twice for a trunacated case.
>
>
I suppose that's a rarer case that we don't necessarily have to optimize
for. I don't think it will do any harm, but is it even possible to avoid?
There are already some other duplications in the driver, for example in
arm_spe_pmu_stop() we call arm_spe_pmu_disable_and_drain_local() which
drains, and then arm_spe_pmu_buf_get_fault_act() which also drains again.
>> switch (act) {
>> case SPE_PMU_BUF_FAULT_ACT_FATAL:
>> /*
>> - * If a fatal exception occurred then leaving the profiling
>> - * buffer enabled is a recipe waiting to happen. Since
>> - * fatal faults don't always imply truncation, make sure
>> - * that the profiling buffer is disabled explicitly before
>> - * clearing the syndrome register.
>> + * To complete the full disable sequence, also disable profiling
>> + * at EL0 and EL1, we don't want to continue at all anymore.
>> */
>> - arm_spe_pmu_disable_and_drain_local();
>> + write_sysreg_s(0, SYS_PMSCR_EL1);
>> break;
>> case SPE_PMU_BUF_FAULT_ACT_OK:
>> /*
>> @@ -679,18 +692,14 @@ static irqreturn_t arm_spe_pmu_irq_handler(int irq, void *dev)
>> * PMBPTR might be misaligned, but we'll burn that bridge
>> * when we get to it.
>> */
>> - if (!(handle->aux_flags & PERF_AUX_FLAG_TRUNCATED)) {
>> + if (!(handle->aux_flags & PERF_AUX_FLAG_TRUNCATED))
>> arm_spe_perf_aux_output_begin(handle, event);
>> - isb();
>
> I am a bit suspecious we can remove this isb().
>
> As a reference to the software usage PKLXF in Arm ARM (DDI 0487 L.a),
> after enable TRBE trace unit, an ISB is mandatory. Maybe check a bit
> for this?
>
> Thanks,
> Leo
>
Wasn't this isb() to separate the programming of the registers with the
status register clear at the end of this function to enable profiling?
But now we enable profiling with the write to PMBLIMITR_EL1 in
arm_spe_perf_aux_output_begin() and the last thing here is the ERET.
That's specifically mentioned as enough synchronization in PKLXF:
In the common case, this is an ERET instruction that returns to a
different Exception level where tracing is allowed.
>> - }
>> break;
>> case SPE_PMU_BUF_FAULT_ACT_SPURIOUS:
>> /* We've seen you before, but GCC has the memory of a sieve. */
>> break;
>> }
>>
>> - /* The buffer pointers are now sane, so resume profiling. */
>> - write_sysreg_s(0, SYS_PMBSR_EL1);
>> return IRQ_HANDLED;
>> }
>>
>>
>> --
>> 2.34.1
>>
>>
next prev parent reply other threads:[~2025-07-07 12:04 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-01 15:31 [PATCH 0/3] perf: arm_spe: Add support for SPE VM interface James Clark
2025-07-01 15:31 ` [PATCH 1/3] perf: arm_spe: Add barrier before enabling profiling buffer James Clark
2025-07-04 14:04 ` Leo Yan
2025-07-07 11:22 ` James Clark
2025-07-08 14:40 ` Alexandru Elisei
2025-07-01 15:31 ` [PATCH 2/3] perf: arm_spe: Disable buffer before writing to PMBPTR_EL1 or PMBSR_EL1 James Clark
2025-07-04 15:50 ` Leo Yan
2025-07-07 11:39 ` James Clark [this message]
2025-07-07 15:37 ` Leo Yan
2025-07-08 14:45 ` Alexandru Elisei
2025-07-09 10:08 ` Alexandru Elisei
2025-07-14 8:58 ` Leo Yan
2025-07-21 13:20 ` James Clark
2025-07-21 15:21 ` Leo Yan
2025-07-22 14:46 ` James Clark
2025-07-30 9:50 ` Alexandru Elisei
2025-07-09 10:09 ` Alexandru Elisei
2025-07-01 15:31 ` [PATCH 3/3] perf: arm_spe: Add support for SPE VM interface James Clark
2025-08-01 13:28 ` [PATCH 0/3] " Alexandru Elisei
2025-08-04 16:00 ` James Clark
2025-08-04 21:49 ` Suzuki K Poulose
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=b77f12e7-ea3f-4c57-9706-ff8e32721cc8@linaro.org \
--to=james.clark@linaro.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=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;
as well as URLs for NNTP newsgroup(s).