Re: [PATCH v2 1/2] perf cs-etm: Fix decoding for sparse CPU maps

[Leo Yan <leo.yan@arm.com>]

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