On 14/07/2025 2:26 pm, Will Deacon wrote:
On Thu, Jun 05, 2025 at 11:49:00AM +0100, James Clark wrote:
FEAT_SPEv1p4 (optional from Armv8.8) adds some new filter bits, so
remove them from the previous version's RES0 bits using
PMSEVFR_EL1_RES0_V1P4_EXCL. It also makes some previously available bits
unavailable again, so add those back using PMSEVFR_EL1_RES0_V1P4_INCL.
E.g:
E[30], bit [30]
When FEAT_SPEv1p4 is _not_ implemented ...
FEAT_SPE_V1P3 has the same filters as V1P2 so explicitly add it to the
switch.
Reviewed-by: Leo Yan <leo.yan@xxxxxxx>
Tested-by: Leo Yan <leo.yan@xxxxxxx>
Signed-off-by: James Clark <james.clark@xxxxxxxxxx>
---
arch/arm64/include/asm/sysreg.h | 7 +++++++
drivers/perf/arm_spe_pmu.c | 5 ++++-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index f1bb0d10c39a..880090df3efc 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -358,6 +358,13 @@
(PMSEVFR_EL1_RES0_IMP & ~(BIT_ULL(18) | BIT_ULL(17) | BIT_ULL(11)))
#define PMSEVFR_EL1_RES0_V1P2 \
(PMSEVFR_EL1_RES0_V1P1 & ~BIT_ULL(6))
+#define PMSEVFR_EL1_RES0_V1P4_EXCL \
+ (BIT_ULL(2) | BIT_ULL(4) | GENMASK_ULL(10, 8) | GENMASK_ULL(23, 19))
+#define PMSEVFR_EL1_RES0_V1P4_INCL \
+ (GENMASK_ULL(31, 26))
+#define PMSEVFR_EL1_RES0_V1P4 \
+ (PMSEVFR_EL1_RES0_V1P4_INCL | \
+ (PMSEVFR_EL1_RES0_V1P2 & ~PMSEVFR_EL1_RES0_V1P4_EXCL))
/* Buffer error reporting */
#define PMBSR_EL1_FAULT_FSC_SHIFT PMBSR_EL1_MSS_SHIFT
diff --git a/drivers/perf/arm_spe_pmu.c b/drivers/perf/arm_spe_pmu.c
index 3efed8839a4e..d9f6d229dce8 100644
--- a/drivers/perf/arm_spe_pmu.c
+++ b/drivers/perf/arm_spe_pmu.c
@@ -701,9 +701,12 @@ static u64 arm_spe_pmsevfr_res0(u16 pmsver)
case ID_AA64DFR0_EL1_PMSVer_V1P1:
return PMSEVFR_EL1_RES0_V1P1;
case ID_AA64DFR0_EL1_PMSVer_V1P2:
+ case ID_AA64DFR0_EL1_PMSVer_V1P3:
+ return PMSEVFR_EL1_RES0_V1P2;
+ case ID_AA64DFR0_EL1_PMSVer_V1P4:
/* Return the highest version we support in default */
default:
- return PMSEVFR_EL1_RES0_V1P2;
+ return PMSEVFR_EL1_RES0_V1P4;
See my reply [1] to Leo about this function, but I think we should just
remove it.
Will
[1] https://lore.kernel.org/all/20250707-arm_spe_support_hitm_overhead_v1_public-v3-0-33ea82da3280@xxxxxxx/
We're only refusing filters that we know for sure are RES0. Unless
there's a mistake, the ones that are maybes are still up to userspace to
decide whether it wants to use them or not.
I think it could be quite useful for some automated tool to fall back to
another behavior if it needs an event that isn't implemented.
If they were _all_ defined as maybes like "When FEAT_SPEv1p4 is
implemented or filtering on event 2 is optionally supported" then I
would agree it's not definite enough to bother restricting them. But a
lot of them are known for sure like "When FEAT_SPEv1p4 is not
implemented ...", so I don't see the harm in preventing use of those.
Or as I mentioned in the other thread if we think we can probe the valid
filters that would be even better.
Thanks
James
