On Mon, Jan 19, 2026 at 03:16:01PM +0000, James Clark wrote:
[...]
/* * If this AUX event was inside this buffer somewhere, create a new auxtrace event@@ -3095,6 +3095,7 @@ static int cs_etm__queue_aux_fragment(struct perf_session *session, off_t file_o auxtrace_fragment.auxtrace = *auxtrace_event; auxtrace_fragment.auxtrace.size = aux_size; auxtrace_fragment.auxtrace.offset = aux_offset;
auxtrace_fragment.auxtrace.idx = etmq->queue_nr;I am still confused about this. Because above auxtrace will be queued on cs_etm queues, should we convert from the generic buffer index to the cs_etm specific one? E.g.,
auxtrace_fragment.auxtrace.idx = auxtrace_event->cpu;
This is basically what the change is already doing. etmq->queue_nr == CPU because cs_etm__setup_queue() is called for every CPU up to max_cpu, not only for ones that were recorded so it has a 1:1 mapping. Using etmq->queue_nr also works in per-thread mode where queue 0 is used, which your suggestion doesn't handle. Otherwise they would be equivalent.
Indeed, per-thread mode needs to be handled separately.
On the Juno board (6 CPUs), I see "etmq->queue_nr=6". It seems a bit odd that this value is used as the index. Even in per-thread mode, the index is still set to 6. For correctness, should we instead set the index to the CPU ID, and use 0 for per-thread mode?
To be honest the whole decoder has become hacks on top of hacks. I think we might want to do a full from scratch re-write when we come to do the proper timestamp to MMAP event correlation or the change to not keep resetting the decoder for TRBE wrap mode.
BTW, if my understanding above is valid, it is good to go through the cs_etm.c file for the "idx <-> CPU ID" conversion.
Do you mean there are other mistakes?
Yes.
I did check the rest and did some testing and didn't see any issues.
Thanks a lot for the checking.
Leo