On Tue, Jul 15, 2025 at 02:04:18PM +0100, James Clark wrote:
On 14/07/2025 3:04 pm, Will Deacon wrote:
On Thu, Jun 05, 2025 at 11:49:05AM +0100, James Clark wrote:
@@ -406,6 +416,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, data_src_filter))
+ reg |= PMSFCR_EL1_FDS;
Is the polarity correct here? The description of PMSDSFR_EL1.S<m> suggests
that setting bits to 1 _excludes_ the FDS filtering.
Setting filter bits to 1 means that samples matching are included. Setting
bits to 0 means that they are excluded. And PMSFCR_EL1.FDS enables filtering
as a whole, so if the user sets any filter bit to 1 we want to enable
filtering:
PMSDSFR_EL1.S<m>
0b0 If PMSFCR_EL1.FDS is 1, do not record load operations that have
bits [5:0] of the Data Source packet set to <m>.
0b1 Load operations with Data Source <m> are unaffected by
PMSFCR_EL1.FDS.
I think it's all the right way around and it ends up being the same as the
other filters in SPE. Because we're using any bit being set to enable the
filtering, the only thing you can't do is enable filtering with a 0 filter,
but I didn't think that was useful. See the previous discussion on this
here:
https://lore.kernel.org/all/5752f039-51c1-4452-b5df-03ff06da7be3@xxxxxxxxxx/
Reading the "Data source filtering" section in the docs change at the end
might help too.
Sorry, but I still don't get it :/
afaict, if any of the bits in 'data_src_filter' are _zero_ then we
should set PMSFCR_EL1.FDS. That also means that a mask of zero means all
loads are filtered, which is what the architecture says and is what we
should provide to userspace.
Will