linux-kernel - Re: [RFC PATCH] perf: Handle multiple formatted AUX records

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]

Date:   Mon, 25 Jan 2021 10:45:06 +0000
From:   Suzuki K Poulose <suzuki.poulose@....com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        linux-kernel@...r.kernel.org, coresight@...ts.linaro.org,
        Ingo Molnar <mingo@...hat.com>, will@...nel.org,
        mark.rutland@....com, mike.leach@...aro.org, al.grant@....com,
        anshuman.khandual@....com, mathieu.poirier@...aro.org,
        linux-arm-kernel@...ts.infradead.org, jolsa@...hat.com,
        acme@...nel.org
Subject: Re: [RFC PATCH] perf: Handle multiple formatted AUX records

Hi Peter

On 1/25/21 10:25 AM, Peter Zijlstra wrote:
> On Fri, Jan 22, 2021 at 03:18:29PM +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.
>>
>> This patch adds a new flag to indicate the trace format
>> for the given record. Also, includes the changes that
>> demonstrates how this can be used in the CoreSight PMU
>> to solve the problem.
>>
>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@....com>
>> ---
> 
>> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
>> index b15e3447cd9f..ea7dcc7b30f0 100644
>> --- a/include/uapi/linux/perf_event.h
>> +++ b/include/uapi/linux/perf_event.h
>> @@ -1109,6 +1109,7 @@ enum perf_callchain_context {
>>   #define PERF_AUX_FLAG_OVERWRITE		0x02	/* snapshot from overwrite mode */
>>   #define PERF_AUX_FLAG_PARTIAL		0x04	/* record contains gaps */
>>   #define PERF_AUX_FLAG_COLLISION		0x08	/* sample collided with another */
>> +#define PERF_AUX_FLAG_ALT_FMT		0x10	/* this record is in alternate trace format */
> 
> Since we have a whole u64, do we want to reserve a whole nibble (or
> maybe even a byte) for a format type? Because with a single bit like
> this, we'll kick ourselves when we end up with the need for a 3rd format
> type.
> 

Sure, makes sense. We could do:

#define PERF_AUX_FLAG_PMU_FORMAT_TYPE_MASK	0xff00

Additionally, the values could be allocated by individual PMUs and
interpreted by the corresponding counterpart. That way we don't
have to worry about centralized allocation of the "TYPE" fields.

e,g:

#define PERF_AUX_FLAG_CORESIGHT_FORMAT_CORESIGHT	0x0000
#define PERF_AUX_FLAG_CORESIGHT_FORMAT_RAW		0x0100

#define PERF_AUX_FLAG_RANDOM_PMU_FORMAT_FMT1		0x0000
#define PERF_AUX_FLAG_RANDOM_PMU_FORMAT_FMT2		0x0100


What do you think ?

Cheers
Suzuki