linux-kernel - Re: [PATCH v4 02/19] perf: aux: Add CoreSight PMU buffer formats

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: <f41a9702-b7b3-c4e8-cc6c-c66bb0fdbb27@arm.com>
Date:   Mon, 22 Mar 2021 12:29:57 +0000
From:   Suzuki K Poulose <suzuki.poulose@....com>
To:     Mathieu Poirier <mathieu.poirier@...aro.org>
Cc:     linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        mike.leach@...aro.org, anshuman.khandual@....com,
        leo.yan@...aro.org, Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH v4 02/19] perf: aux: Add CoreSight PMU buffer formats

On 16/03/2021 17:04, Mathieu Poirier wrote:
> On Thu, Feb 25, 2021 at 07:35:26PM +0000, Suzuki K Poulose wrote:
>> CoreSight PMU supports aux-buffer for the ETM tracing. The trace
>> generated by the ETM (associated with individual CPUs, like Intel PT)
>> is captured by a separate IP (CoreSight TMC-ETR/ETF until now).
>>
>> The TMC-ETR applies formatting of the raw ETM trace data, as it
>> can collect traces from multiple ETMs, with the TraceID to indicate
>> the source of a given trace packet.
>>
>> Arm Trace Buffer Extension is new "sink" IP, attached to individual
>> CPUs and thus do not provide additional formatting, like TMC-ETR.
>>
>> Additionally, a system could have both TRBE *and* TMC-ETR for
>> the trace collection. e.g, TMC-ETR could be used as a single
>> trace buffer to collect data from multiple ETMs to correlate
>> the traces from different CPUs. It is possible to have a
>> perf session where some events end up collecting the trace
>> in TMC-ETR while the others in TRBE. Thus we need a way
>> to identify the type of the trace for each AUX record.
>>
> 
> The gist of this patch is to introduce formatted and raw trace format.  To me
> the above paragraph brings confusion to the changelog, especially since we don't
> allow events belonging to the same session to use different types of sinks.  I
> would simply remove it.

This is not entirely correct. We could still have different formatted
trace in a *session* but not for an *event* in the session. i.e,
imagine a system wide/task bound (not per-thread) session, where there
are events created per-CPU and bound to the CPU. Each of these CPUs
could have different types of preferred sink and thus, we could have
a single session with an AUX record per CPU event, with different
formats. However any AUX record is guaranteed to be of the same type.
And this is why the flag bit is important, so that the perf tool
could create a decoder for an AUX record stream looking at the type.

>   
>> Define the trace formats exported by the CoreSight PMU.
>> We don't define the flags following the "ETM" as this
>> information is available to the user when issuing
>> the session. What is missing is the additional
>> formatting applied by the "sink" which is decided
>> at the runtime and the user may not have a control on.
>>
>> So we define :
>>   - CORESIGHT format (indicates the Frame format)
>>   - RAW format (indicates the format of the source)
>>
>> The default value is CORESIGHT format for all the records
>> (i,e == 0). Add the RAW format for others that use
>> raw format.
>>
>> Cc: Peter Zijlstra <peterz@...radead.org>
>> Cc: Mike Leach <mike.leach@...aro.org>
>> Cc: Mathieu Poirier <mathieu.poirier@...aro.org>
>> Cc: Leo Yan <leo.yan@...aro.org>
>> Cc: Anshuman Khandual <anshuman.khandual@....com>
>> Reviewed-by: Mike Leach <mike.leach@...aro.org>
>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@....com>
>> ---
>> Changes from previous:
>>   - Split from the coresight driver specific code
>>     for ease of merging
>> ---
>>   include/uapi/linux/perf_event.h | 4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
>> index f006eeab6f0e..63971eaef127 100644
>> --- a/include/uapi/linux/perf_event.h
>> +++ b/include/uapi/linux/perf_event.h
>> @@ -1162,6 +1162,10 @@ enum perf_callchain_context {
>>   #define PERF_AUX_FLAG_COLLISION			0x08	/* sample collided with another */
>>   #define PERF_AUX_FLAG_PMU_FORMAT_TYPE_MASK	0xff00	/* PMU specific trace format type */
>>   
>> +/* CoreSight PMU AUX buffer formats */
>> +#define PERF_AUX_FLAG_CORESIGHT_FORMAT_CORESIGHT	0x0000 /* Default for backward compatibility */
>> +#define PERF_AUX_FLAG_CORESIGHT_FORMAT_RAW		0x0100 /* Raw format of the source */
>> +
> 
> Is "CORESIGHT" really a format?  We are playing with words and the end result is
> the same but I think PERF_AUX_FLAG_CORESIGHT_FORMAT_FORMATTED would be best, or
> event:

It is really CoreSight FRAME Format. So unless we specify the "actual" 
format, which is CoreSight Frame format, simply FORMATTED doesn't
distinguish it from a new format that could be applied in the future.

I would prefer to retain the above names to indicate the definitions
apply to CORESIGH pmu FORMAT flags.

> 
> #define PERF_AUX_FLAG_CORESIGHT_TRACE_FORMATTED         0x0000 /* Default for backward compatibility */
> #define PERF_AUX_FLAG_CORESIGHT_TRACE_RAW               0x0100 /* Raw format of the source */
> 
> Regardless, for patches 01 and 02: >
> Reviewed-by: Mathieu Poirier <mathieu.poirier@...aro.org>

Thanks
Suzuki

> 
>>   #define PERF_FLAG_FD_NO_GROUP		(1UL << 0)
>>   #define PERF_FLAG_FD_OUTPUT		(1UL << 1)
>>   #define PERF_FLAG_PID_CGROUP		(1UL << 2) /* pid=cgroup id, per-cpu mode only */
>> -- 
>> 2.24.1
>>