linux-kernel - Re: [PATCH v7 13/13] coresight: docs: Document etm4x timestamp interval option

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20251127103258.GQ724103@e132581.arm.com>
Date: Thu, 27 Nov 2025 10:32:58 +0000
From: Leo Yan <leo.yan@....com>
To: Al Grant <Al.Grant@....com>
Cc: James Clark <james.clark@...aro.org>,
	Mike Leach <mike.leach@...aro.org>,
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
	Jonathan Corbet <corbet@....net>,
	Randy Dunlap <rdunlap@...radead.org>,
	"coresight@...ts.linaro.org" <coresight@...ts.linaro.org>,
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>
Subject: Re: [PATCH v7 13/13] coresight: docs: Document etm4x timestamp
 interval option

On Wed, Nov 26, 2025 at 03:36:58PM +0000, Al Grant wrote:

[...]

> > >> As far as I recall when this command line parameter was a bool then:
> > >> perf -e cs_etm/timestamp/ <program>
> > >> is sufficient to turn on timestamping.
> > >
> > > Hmm... with the latest perf, we must assign value to `timestamp`,
> > > otherwise perf will report error:
> > >
> > >    # /mnt/build/perf record -e cs_etm/timestamp/ -C 0 -- taskset -c 0 ls
> > >    event syntax error: 'cs_etm/timestamp/'
> > >                         \___ Bad event or PMU
> > >
> > >    Unable to find PMU or event on a PMU of 'cs_etm'
> > >
> > >    event syntax error: 'cs_etm/timestamp/'
> > >                         \___ no value assigned for term
> > >
> > >    event syntax error: 'cs_etm/timestamp/'
> > >                         \___ no value assigned for term
> > >    Run 'perf list' for a list of valid events
> > >
> > >
> > 
> > That's unfortunate and not what I expected. And I don't think it makes sense to
> > remove that validation from Perf. The test uses "timestamp=1"
> > so I didn't notice.
> > 
> > Can we accept that people are most likely using the defaults so timestamps are
> > already on and they wouldn't be using it? The only real use case of that at the
> > moment is to do timestamp=0 and that doesn't fail.
> > 
> > Although it's not the default for per-thread mode and I did find the OpenCSD
> > HOWTO.md uses it as an example. timestamps make less sense in per-thread
> > mode as you don't need to correlate between CPUs or watch for context
> > switches.
> 
> Timestamps have a more specialised use in per-thread mode, they are
> as you say less essential for switching in the right context to decode
> the trace, and less relevant to BOLT/AutoFDO style usage where the
> trace is collapsed into a heat-map profile.
> 
> But trace can also be used to get a detailed timeline of CPU activity -
> a non-invasive timeline that can trace even through interrupt-disabled
> kernel code. And for that, having a global constant-frequency timebase
> becomes more useful, both in its own right, and to line up traces
> from each CPU with other CPUs and system-level traces.
> It's also the only way we have to indirectly observe CPU frequency
> adjustments. (Intel's Processor Trace, which is generally similar to
> ETM/ETE, has specific packets that trace CPU frequency changes.)

Just clarify a bit to make sure us on the same page.

This series does not break timestamp functionality, it just changes the
PMU format 'timestamp' from 1-bit to 4-bits for counter support.  The
updated 'timestamp' format still supports per-thread mode and CPU wise
trace modes.

The only difference is now users need to specify 'cs_etm/timestamp=1/'
rather than 'cs_etm/timestamp/' when enabling timestamp.  Given PMU
format is not an ABI, it is fine for me for the updated format.

To avoid confusion for users, a well-written document is deserved —
which is exactly this patch for.  And perf log would be helpful.  I
think we are well prepared for the change.

Thanks,
Leo