From: Alexandru Elisei <alexandru.elisei@arm.com>
To: James Clark <james.clark@linaro.org>
Cc: Will Deacon <will@kernel.org>,
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>,
alexandru.elisei@arm.com, linux-arm-kernel@lists.infradead.org,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] perf: arm_spe: Add support for SPE VM interface
Date: Fri, 1 Aug 2025 14:28:11 +0100 [thread overview]
Message-ID: <aIzA632hiAldjJQQ@raptor> (raw)
In-Reply-To: <20250701-james-spe-vm-interface-v1-0-52a2cd223d00@linaro.org>
Hi,
On Tue, Jul 01, 2025 at 04:31:56PM +0100, James Clark wrote:
> SPE can be used from within a guest as long as the driver adheres to the
> new VM interface spec [1]. Because the driver should behave correctly
> whether it's running in a guest or not, the first patches are marked as
> a fix. Furthermore, in future versions of the architecture the PE will
> be allowed to behave in the same way.
>
> The last patch adds new behavior to make it easier for guests to be
> able to reserve large buffers. It's not strictly necessary, so it's not
> marked as a fix.
I had a look at the patches, and they all look ok to me, so for the series:
Reviewed-by: Alexandru Elisei <alexandru.elisei@arm.com>
I also tested the series by hacking SPE virtualization support in KVM:
- without these changes, the SPE driver gets into an infinite loop because it
clears PMBSR_EL1.S before clearing PMBLIMITR_EL.E, and the hypervisor is
allowed to ignore the write to PMBSR_EL1.
- with these changes, that doesn't happen.
- ran perf for about a day in a loop in a virtual machine and didn't notice
anything out of the ordinary.
- ran perf for about a day in a loop on baremetal and similary everything looked
alright.
- checked that the SPE driver correctly decodes the maximum buffer size for
sizes 4M, 2M (2M is right at the boundary between the two encoding schemes)
and 1M; that's also correctly reflected in
/sys/devices/platform/<spe>/arm_spe_0/caps/max_buffer_size.
- checked that perf is not allowed to use a buffer larger than the maximum.
- checked that the SPE driver correctly detects a buffer size management event.
So:
Tested-by: Alexandru Elisei <alexandru.elisei@arm.com>
While testing I noticed two things:
1. When perf tries to use a buffer larger than the maximum, the error is EINVAL
(22):
# cat /sys/devices/platform/spe/arm_spe_0/caps/max_buff_size
4194304
# perf record -ae arm_spe// -m,16M -- sleep 10
failed to mmap with 22 (Invalid argument)
(used 16M as the buffer size because what the driver ends up programming is half
that).
I would have expected to get back ENOMEM (12), that seems less ambiguous to me.
I had to hack the driver to print an error message to dmesg when the max buffer
size is exceed to make sure that's why I was seeing the error message in perf,
and it wasn't because of something else. I get that that's because .setup_aux()
can only return NULL on error, but feels like there's room for improvement here.
2. A hypervisor is allowed to inject a buffer size event even though the buffer
set by the guest is smaller than the maximum advertised. For example, this can
happen if there isn't enough memory to pin the buffer, or if the limit on pinned
memory is exceeded in the hypervisor (implementation specific behaviour, not
mandated in DEN0154, of course).
In this situation, when the SPE driver gets a buffer size management event
injected by the hypervisor, there is no way for the driver to communicate it to
the perf instance, and the profiled process continues executing even though
profiling has stopped.
That's not different from what happens today with buffer management events, but
unlike the other events, which aren't under the control of userspace, the buffer
size event is potentially recoverable if userspace restarts perf with a smaller
buffer.
Do you think there's something that can be done to improve this situation?
Thanks,
Alex
>
> [1]: https://developer.arm.com/documentation/den0154/latest/
>
> Signed-off-by: James Clark <james.clark@linaro.org>
> ---
> James Clark (3):
> perf: arm_spe: Add barrier before enabling profiling buffer
> perf: arm_spe: Disable buffer before writing to PMBPTR_EL1 or PMBSR_EL1
> perf: arm_spe: Add support for SPE VM interface
>
> arch/arm64/include/asm/sysreg.h | 1 +
> arch/arm64/tools/sysreg | 6 ++++-
> drivers/perf/arm_spe_pmu.c | 60 ++++++++++++++++++++++++++++++++---------
> 3 files changed, 54 insertions(+), 13 deletions(-)
> ---
> base-commit: d0b3b7b22dfa1f4b515fd3a295b3fd958f9e81af
> change-id: 20250609-james-spe-vm-interface-2bb41e238072
>
> Best regards,
> --
> James Clark <james.clark@linaro.org>
>
next prev parent reply other threads:[~2025-08-01 13:32 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
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 ` Alexandru Elisei [this message]
2025-08-04 16:00 ` [PATCH 0/3] " 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=aIzA632hiAldjJQQ@raptor \
--to=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=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).