linux-kernel - Re: [PATCH v4 00/22] perf: Add infrastructure and support for Intel PT

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: <CANLsYkwdRBfOFb5c6=nb+1qzt1R=MJ4NbPWymgp5J6iRs02KDQ@mail.gmail.com>
Date:	Fri, 5 Sep 2014 07:34:21 -0600
From:	Mathieu Poirier <mathieu.poirier@...aro.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Pawel Moll <pawel.moll@....com>,
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
	Ingo Molnar <mingo@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Robert Richter <rric@...nel.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Mike Galbraith <efault@....de>,
	Paul Mackerras <paulus@...ba.org>,
	Stephane Eranian <eranian@...gle.com>,
	Andi Kleen <ak@...ux.intel.com>,
	"kan.liang@...el.com" <kan.liang@...el.com>,
	Michael Williams <Michael.Williams@....com>,
	"ralf@...ux-mips.org" <ralf@...ux-mips.org>,
	Al Grant <Al.Grant@....com>, Deepak Saxena <dsaxena@...aro.org>
Subject: Re: [PATCH v4 00/22] perf: Add infrastructure and support for Intel PT

On 4 September 2014 02:26, Peter Zijlstra <peterz@...radead.org> wrote:
> On Tue, Sep 02, 2014 at 02:18:16PM -0600, Mathieu Poirier wrote:
>> Pawell, many thanks for looping me in.
>>
>> I am definitely not a perf-internal guru and as such won't be able to
>> comment on the implementation.  On the flip side it is easy for me to see
>> how the work on coresight done at Linaro can be made to tie-in what
>> Alexander is proposing.  Albeit not at the top of the priority list at this
>> time, integration with perf (and ftrace) is definitely on the roadmap.
>>
>> Powell is correct in his statement that Linaro's work in HW trace decoding
>> is (currently) mainly focused on processor tracing but that will change
>> when we have the basic infrastructure upstreamed.
>>
>> Last but not least it would be interesting to have more information on the
>> "sideband data".  With coresight we have something called "metadata", also
>> related to how the trace source was configured and instrumental to proper
>> trace decoding.  I'm pretty sure we are facing the same problems.
>
> So we use the sideband or AUX data stream to export the 'big' data
> stream generated by the CPU in an opaque manner. For every AUX data
> block 'posted' we issue an event into the regular data buffer that
> describes it.

In the context of "describe it" written above, what kind of
information one would typically find in that description?

>
> I was assuming that both ARM and MIPS would generate a single data
> stream as well. So please do tell more about your meta-data; is that a
> one time thing or a second continuous stream of data, albeit smaller
> than the main stream?

Coresight does indeed generate a single steam of compressed data.
Depending on the tracing specifics that were requested by the use case
(trace engine configuration) the format of the packets in the
compressed stream will change.  Since the compressed stream itself
doesn't carry clues about the formatting information, knowledge of how
the trace engine was configured is mandatory for the proper decoding
of the trace stream.

Metadata refer to exactly that - the configuration of the trace
engine.  It has to be somehow lumped with the trace stream for off
target analysis.

>
> The way I read your explanation it is a one time blob generated once you
> setup the hardware.

Correct.

> I suppose we could either dump it once into the
> normal data stream or maybe dump it once every time we generate an AUX
> buffer event into the normal data stream -- if its not too big.

Right, there is a set of meta-data to be generated with each trace
run.  With the current implementation a "trace run" pertains to all
the information collected between the beginning and end of a trace
scenario.  Future work involve triggering a DMA transfer of the full
coresight buffer to a kernel memory area, something that is probably
close to the "buffer event" you are referring to.

When we get there I also agree that metadata should be lumped with
each buffer event, removing the need to have the first buffer in the
set to be able to decode all the other buffers.

>
> In any case, can you point us to public documentation of the ARM
> CoreSight stuff and maybe provide a short summary for the tl;dr crowd?

Absolutely.

Information on metadata: [1]
Current coresight patchset: [2]
Quick summary on coresight: [3]
Technical details on Coresight: [4]

Best regards,
Mathieu


[1]. http://people.linaro.org/~mathieu.poirier/coresight/cs-decode.pdf
[2]. https://lkml.org/lkml/2014/8/27/479
[3]. https://lkml.org/lkml/2014/8/27/467
[4]. http://infocenter.arm.com/help/index.jsp (section "CoreSight
on-chip trace and debug")
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/