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

[Peter Zijlstra]

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@xxxxxxx>
> ---

> 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.