linux-kernel - Re: [PATCH 07/10] perf: arm_spe: Add support for filtering on data source

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250520161003.GT412060@e132581.arm.com>
Date: Tue, 20 May 2025 17:10:03 +0100
From: Leo Yan <leo.yan@....com>
To: James Clark <james.clark@...aro.org>
Cc: Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>, Mark Rutland <mark.rutland@....com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Namhyung Kim <namhyung@...nel.org>,
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
	Jiri Olsa <jolsa@...nel.org>, Ian Rogers <irogers@...gle.com>,
	Adrian Hunter <adrian.hunter@...el.com>,
	Jonathan Corbet <corbet@....net>, Marc Zyngier <maz@...nel.org>,
	Oliver Upton <oliver.upton@...ux.dev>,
	Joey Gouly <joey.gouly@....com>,
	Suzuki K Poulose <suzuki.poulose@....com>,
	Zenghui Yu <yuzenghui@...wei.com>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linux-perf-users@...r.kernel.org, linux-doc@...r.kernel.org,
	kvmarm@...ts.linux.dev
Subject: Re: [PATCH 07/10] perf: arm_spe: Add support for filtering on data
 source

On Tue, May 20, 2025 at 04:00:59PM +0100, James Clark wrote:
> On 20/05/2025 2:46 pm, Leo Yan wrote:
> > On Tue, May 06, 2025 at 12:41:39PM +0100, 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 setting bits 0 and 3 filters packets from
> > > data sources 0 OR 3.
> > 
> > As Arm ARM says:
> > 
> >    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.
> > 
> > We need extra handling for this configuration (0b0 means filtering,
> > 0b1 means no affaction):
> > 
> > - By default, the driver should set all bits in the 'data_src_filter'
> >    field.
> > 
> > - The perf tool needs an extra patch in userspace to initialize all
> >    bits in config4 unless user specify other values.
> > 
> 
> Did you take into account PMSFCR_EL1.FDS being set automatically?

Good point. TBH, I did not give it enough consideration until your
remdinding, but let me elaborate on why I suggested the approach above.

> I think the wording is slightly confusing but I tested it on the model and it works.
> 
> If PMSFCR_EL1.FDS == 0 then PMSDSFR_EL1 does nothing, and if the data source
> filter isn't set by the user then FDS isn't set so there's no need to set
> all the bits in the filter to 1. Once the user asks for any filter then we
> set FDS, at which point it's whatever filter they asked for. They can set
> all the bits if they want, or just one.
> 
> This is same way PMSFCR_EL1.FT already works. If the user asks for any
> filter then it's set automatically, but we don't allow the user to ask for
> "no filters" but with FT set.
> 
> So the only thing we can't do is filter out samples with _any_ data source.
> Which would be PMSFCR_EL1.FDS == 1 and PMSDSFR_EL1 == 0. But I don't think
> that's useful, and there are other filters to get you all or most of the way
> there.

My suggestion is coming for handling the case you mentioned.  Let us see
the combinations:

 PMSFCR_EL1.FDS == 0
 PMSDSFR_EL1 == 0xFFFF,FFFF,FFFF,FFFF
   No filtering on data source

 PMSFCR_EL1.FDS == 1
 PMSDSFR_EL1 == 0xFFFF,FFFF,FFFF,FFFF
   No filtering on data source

 PMSFCR_EL1.FDS == 0
 PMSDSFR_EL1 == 0x0
   No filtering on data source

 PMSFCR_EL1.FDS == 1
 PMSDSFR_EL1 == 0x0
   Filtering on all data source

If 'PMSFCR_EL1.FDS == 0 and PMSDSFR_EL1 == 0xFFFF,FFFF,FFFF,FFFF' is
initialized state, when a user set all bits to '1' for the data source
filter, then no matter we enable or disable FDS bit, it can work as
expected for disabling filtering.

If 'PMSFCR_EL1.FDS == 0 and PMSDSFR_EL1 == 0x0' is the init state, as
you said, when user passed 0xFFFF,FFFF,FFFF,FFFF for data filter, we
cannot distinguish it from the init state, as a result, we will fail
to handle this case.

How about you think?

Thanks,
Leo