linux-kernel - Re: [PATCH 1/3] perf test: Support arch-specific shell tests

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: <4763aca8-a140-4291-b12e-e03cc0d82bdd@linaro.org>
Date: Fri, 23 May 2025 11:48:26 +0100
From: James Clark <james.clark@...aro.org>
To: Ian Rogers <irogers@...gle.com>, Namhyung Kim <namhyung@...nel.org>
Cc: Arnaldo Carvalho de Melo <acme@...nel.org>,
 Kan Liang <kan.liang@...ux.intel.com>, Jiri Olsa <jolsa@...nel.org>,
 Adrian Hunter <adrian.hunter@...el.com>,
 Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...nel.org>,
 LKML <linux-kernel@...r.kernel.org>, linux-perf-users@...r.kernel.org
Subject: Re: [PATCH 1/3] perf test: Support arch-specific shell tests

On 22/05/2025 9:09 pm, Ian Rogers wrote:
> On Thu, May 22, 2025 at 10:10 AM Namhyung Kim <namhyung@...nel.org> wrote:
>>
>> This is a preparation for shell tests belong to an arch.
> 
> I keep repeating that I don't like arch and I think ideally we'd be
> getting rid of the C arch tests. I just sent out a patch doing this
> for 1 test:
> https://lore.kernel.org/lkml/20250521165317.713463-2-irogers@google.com/
> We should be able to make perf, tests, etc. dependent on a PMU rather
> than an architecture. This means that running perf built for ARM will
> be able to do things running on an instruction emulator on x86. It

In this case for Arm SPE and Coresight you can only generate trace by 
running on a full model or a real CPU, so I'm not sure if we could ever 
get close to running on just an emulator.

> means the tool, the kernel APIs, etc. are generic and new
> architectures like RISC-V can test things. It means cross-platform
> (record on 1 machine type, report on another) can work without
> tripping over load bearing architecture ifdefs. It means that we

I have thought about adding some generic decoding side tests for SPE and 
Coresight, but couldn't really get past the fact that you need to put 
the trace dump _and_ the binaries traced into the git repo. Not only 
would this benefit testing on other arches like you say, but it would 
also lock down that decoding of a known file doesn't regress which we 
can't currently do by generating new trace every time the test runs.

If we ever added this they would be separate tests though so they could 
go in the top level folder, where the ones in the arch folder would 
continue to do record and decode. Maybe naming the folders by PMU could 
work, but you could also have both PMU name and arch name folders like:

Recording/requires hardware:

   tools/perf/arch/arm64/tests/shell/cs_etm/

Cross platform decode tests:

   tools/perf/tests/shell/cs_etm/

Which would mirror how the source files are currently laid out:

  tools/perf/arch/arm/util/cs-etm.c
  tools/perf/util/cs-etm.c

Thanks
James

> benefit from more testing on generic pieces of code on all
> architectures - like sample parsing. We can always strcmp the PMU name
> or the architecture at runtime.
> 
> Structure wise we could have:
> tools/perf/pmu/ibs_op/tests/
> tools/perf/pmu/ibs_op/tests/shell
> 
> It feels noisy compared to just having the shell test in
> tools/perf/tests/shell skip when the PMU isn't present. There are also
> things like library dependencies that aren't clear when we have >1
> directory. I'd prefer if new testing followed the existing model
> rather than this.
> 
> Thanks,
> Ian
>