Re: [RFC 00/11] arm64: coresight: Enable ETE and TRBE | linux-arm-kernel

quoted

Hi Anshuman,

I've not looked in detail at this set yet, but having skimmed through
it  I do have an initial question about the handling of wrapped data
buffers.

With the ETR/ETB we found an issue with the way perf concatenated data
captured from the hardware buffer into a single contiguous data
block. The issue occurs when a wrapped buffer appears after another
buffer in the data file. In a typical session perf would stop trace
and copy the hardware buffer multiple times into the auxtrace buffer.

e.g.

For ETR/ETB we have a fixed length hardware data buffer - and no way
of detecting buffer wraps using interrupts as the tracing is in
progress.

If the buffer is not full at the point that perf transfers it then the
data will look like this:-
1) <async><synced trace data>
easy to decode, we can see the async at the start of the data - which
would be the async issued at the start of trace.

If the buffer wraps we see this:-

2) <unsynced trace data><async><synced trace data>

Again no real issue, the decoder will skip to the async and trace from
there - we lose the unsynced data.

Now the problem occurs when multiple transfers of data occur. We can
see the following appearing as contiguous trace in the auxtrace
buffer:-

3) < async><synced trace data><unsynced trace data><async><synced trace data>

Now the decoder cannot spot the point that the synced data from the
first capture ends, and the unsynced data from the second capture
begins.
This means it will continue to decode into the unsynced data - which
will result in incorrect trace / outright errors. To get round this
for ETR/ETB the driver will insert barrier packets into the datafile
if a wrap event is detected.

4) <async><synced trace data><barrier><unsynced trace
data><async><synced trace data>

This <barrier> has the effect of resetting the decoder into the
unsynced state so that the invalid trace is not decoded. This is a
workaround we have to do to handle the limitations of the ETR / ETB
trace hardware.

For TRBE we do have interrupts, so it should be possible to prevent
the buffer wrapping in most cases - but I did see in the code that
there are handlers for the TRBE buffer wrap management event. Are
there other factors in play that will prevent data pattern 3) from
appearing in the auxtrace buffer?

Regards

Mike

On Sat, 14 Nov 2020 at 05:17, Tingwei Zhang [off-list ref] wrote:

`h`	back out one level
`j`	next message in thread
`k`	previous message in thread
`l`	drill in
`Esc`	close help / fold thread tree
`?`	toggle this help