SPE_FEAT_FDS adds the ability to filter on the data source of packets.
Like the other existing filters, enable filtering with PMSFCR_EL1.FDS
when any of the filter bits are set.
Each bit maps to data sources 0-63 described by bits[0:5] in the data
source packet (although the full range of data source is 16 bits so
higher value data sources can't be filtered on). The filter is an OR of
all the bits, so for example clearing bits 0 and 3 only includes packets
from data sources 0 OR 3.
Invert the filter given by userspace so that the default value of 0 is
equivalent to including all values (no filtering). This allows us to
skip adding a new format bit to enable filtering and still support
excluding all data sources which would have been a filter value of 0 if
not for the inversion.
Tested-by: Leo Yan <leo.yan@arm.com>
Reviewed-by: Leo Yan <leo.yan@arm.com>
Signed-off-by: James Clark <james.clark@linaro.org>
---
drivers/perf/arm_spe_pmu.c | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/drivers/perf/arm_spe_pmu.c b/drivers/perf/arm_spe_pmu.c
index fa50645fedda..617f8a98dd63 100644
--- a/drivers/perf/arm_spe_pmu.c
+++ b/drivers/perf/arm_spe_pmu.c
@@ -87,6 +87,7 @@ struct arm_spe_pmu {
#define SPE_PMU_FEAT_INV_FILT_EVT (1UL << 6)
#define SPE_PMU_FEAT_DISCARD (1UL << 7)
#define SPE_PMU_FEAT_EFT (1UL << 8)
+#define SPE_PMU_FEAT_FDS (1UL << 9)
#define SPE_PMU_FEAT_DEV_PROBED (1UL << 63)
u64 features;
@@ -252,6 +253,10 @@ static const struct attribute_group arm_spe_pmu_cap_group = {
#define ATTR_CFG_FLD_inv_event_filter_LO 0
#define ATTR_CFG_FLD_inv_event_filter_HI 63
+#define ATTR_CFG_FLD_inv_data_src_filter_CFG config4 /* inverse of PMSDSFR_EL1 */
+#define ATTR_CFG_FLD_inv_data_src_filter_LO 0
+#define ATTR_CFG_FLD_inv_data_src_filter_HI 63
+
GEN_PMU_FORMAT_ATTR(ts_enable);
GEN_PMU_FORMAT_ATTR(pa_enable);
GEN_PMU_FORMAT_ATTR(pct_enable);
@@ -268,6 +273,7 @@ GEN_PMU_FORMAT_ATTR(float_filter);
GEN_PMU_FORMAT_ATTR(float_filter_mask);
GEN_PMU_FORMAT_ATTR(event_filter);
GEN_PMU_FORMAT_ATTR(inv_event_filter);
+GEN_PMU_FORMAT_ATTR(inv_data_src_filter);
GEN_PMU_FORMAT_ATTR(min_latency);
GEN_PMU_FORMAT_ATTR(discard);
@@ -288,6 +294,7 @@ static struct attribute *arm_spe_pmu_formats_attr[] = {
&format_attr_float_filter_mask.attr,
&format_attr_event_filter.attr,
&format_attr_inv_event_filter.attr,
+ &format_attr_inv_data_src_filter.attr,
&format_attr_min_latency.attr,
&format_attr_discard.attr,
NULL,
@@ -306,6 +313,10 @@ static umode_t arm_spe_pmu_format_attr_is_visible(struct kobject *kobj,
if (attr == &format_attr_inv_event_filter.attr && !(spe_pmu->features & SPE_PMU_FEAT_INV_FILT_EVT))
return 0;
+ if (attr == &format_attr_inv_data_src_filter.attr &&
+ !(spe_pmu->features & SPE_PMU_FEAT_FDS))
+ return 0;
+
if ((attr == &format_attr_branch_filter_mask.attr ||
attr == &format_attr_load_filter_mask.attr ||
attr == &format_attr_store_filter_mask.attr ||
@@ -430,6 +441,9 @@ static u64 arm_spe_event_to_pmsfcr(struct perf_event *event)
if (ATTR_CFG_GET_FLD(attr, inv_event_filter))
reg |= PMSFCR_EL1_FnE;
+ if (ATTR_CFG_GET_FLD(attr, inv_data_src_filter))
+ reg |= PMSFCR_EL1_FDS;
+
if (ATTR_CFG_GET_FLD(attr, min_latency))
reg |= PMSFCR_EL1_FL;
@@ -454,6 +468,17 @@ static u64 arm_spe_event_to_pmslatfr(struct perf_event *event)
return FIELD_PREP(PMSLATFR_EL1_MINLAT, ATTR_CFG_GET_FLD(attr, min_latency));
}
+static u64 arm_spe_event_to_pmsdsfr(struct perf_event *event)
+{
+ struct perf_event_attr *attr = &event->attr;
+
+ /*
+ * Data src filter is inverted so that the default value of 0 is
+ * equivalent to no filtering.
+ */
+ return ~ATTR_CFG_GET_FLD(attr, inv_data_src_filter);
+}
+
static void arm_spe_pmu_pad_buf(struct perf_output_handle *handle, int len)
{
struct arm_spe_pmu_buf *buf = perf_get_aux(handle);
@@ -791,6 +816,10 @@ static int arm_spe_pmu_event_init(struct perf_event *event)
if (arm_spe_event_to_pmsnevfr(event) & spe_pmu->pmsevfr_res0)
return -EOPNOTSUPP;
+ if (arm_spe_event_to_pmsdsfr(event) != U64_MAX &&
+ !(spe_pmu->features & SPE_PMU_FEAT_FDS))
+ return -EOPNOTSUPP;
+
if (attr->exclude_idle)
return -EOPNOTSUPP;
@@ -866,6 +895,11 @@ static void arm_spe_pmu_start(struct perf_event *event, int flags)
write_sysreg_s(reg, SYS_PMSNEVFR_EL1);
}
+ if (spe_pmu->features & SPE_PMU_FEAT_FDS) {
+ reg = arm_spe_event_to_pmsdsfr(event);
+ write_sysreg_s(reg, SYS_PMSDSFR_EL1);
+ }
+
reg = arm_spe_event_to_pmslatfr(event);
write_sysreg_s(reg, SYS_PMSLATFR_EL1);
@@ -1125,6 +1159,9 @@ static void __arm_spe_pmu_dev_probe(void *info)
if (FIELD_GET(PMSIDR_EL1_EFT, reg))
spe_pmu->features |= SPE_PMU_FEAT_EFT;
+ if (FIELD_GET(PMSIDR_EL1_FDS, reg))
+ spe_pmu->features |= SPE_PMU_FEAT_FDS;
+
/* This field has a spaced out encoding, so just use a look-up */
fld = FIELD_GET(PMSIDR_EL1_INTERVAL, reg);
switch (fld) {
--
2.34.1
On Wed, Oct 29, 2025 at 03:46:02PM +0000, James Clark wrote: > SPE_FEAT_FDS adds the ability to filter on the data source of packets. > Like the other existing filters, enable filtering with PMSFCR_EL1.FDS > when any of the filter bits are set. > > Each bit maps to data sources 0-63 described by bits[0:5] in the data > source packet (although the full range of data source is 16 bits so > higher value data sources can't be filtered on). The filter is an OR of > all the bits, so for example clearing bits 0 and 3 only includes packets > from data sources 0 OR 3. > > Invert the filter given by userspace so that the default value of 0 is > equivalent to including all values (no filtering). This allows us to > skip adding a new format bit to enable filtering and still support > excluding all data sources which would have been a filter value of 0 if > not for the inversion. So from that I'm reading the config4 field will only have like 16 bits, but here: > +#define ATTR_CFG_FLD_inv_data_src_filter_CFG config4 /* inverse of PMSDSFR_EL1 */ > +#define ATTR_CFG_FLD_inv_data_src_filter_LO 0 > +#define ATTR_CFG_FLD_inv_data_src_filter_HI 63 you claim all 64 bits. Also, afaict: #define ATTR_CFG_FLD_min_latency_CFG config2 /* PMSLATFR_EL1.MINLAT */ #define ATTR_CFG_FLD_min_latency_LO 0 #define ATTR_CFG_FLD_min_latency_HI 11 Still has more than 16 bits left. So why exactly are we needing config4? Can we please get a more solid argument?
On 10/11/2025 3:48 pm, Peter Zijlstra wrote: > On Wed, Oct 29, 2025 at 03:46:02PM +0000, James Clark wrote: >> SPE_FEAT_FDS adds the ability to filter on the data source of packets. >> Like the other existing filters, enable filtering with PMSFCR_EL1.FDS >> when any of the filter bits are set. >> >> Each bit maps to data sources 0-63 described by bits[0:5] in the data >> source packet (although the full range of data source is 16 bits so >> higher value data sources can't be filtered on). The filter is an OR of >> all the bits, so for example clearing bits 0 and 3 only includes packets >> from data sources 0 OR 3. >> >> Invert the filter given by userspace so that the default value of 0 is >> equivalent to including all values (no filtering). This allows us to >> skip adding a new format bit to enable filtering and still support >> excluding all data sources which would have been a filter value of 0 if >> not for the inversion. > > So from that I'm reading the config4 field will only have like 16 bits, The _data source_ is 16 bits, but the _data source filter_ is 64 bits. > but here: > >> +#define ATTR_CFG_FLD_inv_data_src_filter_CFG config4 /* inverse of PMSDSFR_EL1 */ >> +#define ATTR_CFG_FLD_inv_data_src_filter_LO 0 >> +#define ATTR_CFG_FLD_inv_data_src_filter_HI 63 > > you claim all 64 bits. > > Also, afaict: > > #define ATTR_CFG_FLD_min_latency_CFG config2 /* PMSLATFR_EL1.MINLAT */ > #define ATTR_CFG_FLD_min_latency_LO 0 > #define ATTR_CFG_FLD_min_latency_HI 11 > > Still has more than 16 bits left. > > > So why exactly are we needing config4? Can we please get a more solid > argument? Each filter bit position maps onto one numerical data source value. The 16 bit field in the data source packet gives us possible data sources from 0 - 65535. The 64 bits of the filter allow us to filter on a subset of data sources (0 - 63), but that uses all 64 bits of the filter with one bit used for each source. I think you are assuming the data source filter can only filter on a single value as if it was interpreted numerically, rather than bitwise? But it's actually interpreted as a separate filter for each bit, which allows the OR semantics that are described in the commit message. It might be clearer if I add a few more words to differentiate "data source" and "filter": Each bit of the 64 bit filter maps to data sources 0-63 described by bits[0:5] in the data source packet (although the full range of data source is 16 bits so higher value data sources can't be filtered on). The filter is an OR of all the filter bits, so for example clearing filter bits 0 and 3 only includes packets from data sources 0 OR 3.
On Tue, Nov 11, 2025 at 10:51:56AM +0000, James Clark wrote: > > > On 10/11/2025 3:48 pm, Peter Zijlstra wrote: > > On Wed, Oct 29, 2025 at 03:46:02PM +0000, James Clark wrote: > > > SPE_FEAT_FDS adds the ability to filter on the data source of packets. > > > Like the other existing filters, enable filtering with PMSFCR_EL1.FDS > > > when any of the filter bits are set. > > > > > > Each bit maps to data sources 0-63 described by bits[0:5] in the data > > > source packet (although the full range of data source is 16 bits so > > > higher value data sources can't be filtered on). The filter is an OR of > > > all the bits, so for example clearing bits 0 and 3 only includes packets > > > from data sources 0 OR 3. > > > > > > Invert the filter given by userspace so that the default value of 0 is > > > equivalent to including all values (no filtering). This allows us to > > > skip adding a new format bit to enable filtering and still support > > > excluding all data sources which would have been a filter value of 0 if > > > not for the inversion. > > > > So from that I'm reading the config4 field will only have like 16 bits, > > The _data source_ is 16 bits, but the _data source filter_ is 64 bits. Ah! > It might be clearer if I add a few more words to differentiate "data source" > and "filter": > > Each bit of the 64 bit filter maps to data sources 0-63 described by > bits[0:5] in the data source packet (although the full range of data > source is 16 bits so higher value data sources can't be filtered on). > The filter is an OR of all the filter bits, so for example clearing > filter bits 0 and 3 only includes packets from data sources 0 OR 3. Yeah, that might've helped :-)
© 2016 - 2026 Red Hat, Inc.