[PATCH 3/3] rfc: perf: cs_etm: Detect pid in VMID for kernel running at EL2

Leo Yan leo.yan at linaro.org
Fri Nov 13 05:42:48 EST 2020


On Fri, Nov 13, 2020 at 09:47:42AM +0000, Suzuki Kuruppassery Poulose wrote:

[...]

> > Rather than heuristic method, I think we can use metadata to store
> > "pid" entry in the function cs_etm_get_metadata(), so that in the
> > record phase, the "pid" is stored into perf data file.
> 
> True, that is a good idea. That makes it future proof.
> 
> > 
> > When decode the trace data, we can retrieve "pid" value from the
> > metadata, and can base on the "pid" value to make decision for using
> > context_id or VMID.
> 
> > 
> > The metadata can be accessed by referring
> > cs_etm_queue::cs_etm_auxtrace::metadata; but the file
> > util/cs-etm-decoder/cs-etm-decoder.c cannot directly access the
> > metadata structure due to "cs_etm_queue" and "cs_etm_auxtrace" both
> > are defined in util/cs-etm.c.  It's better to introduce a helper
> > function in util/cs-etm.c to retrieve "pid" value, like:
> > 
> >    u64 cs_etm__etmq_get_pid_type(struct cs_etm_queue *etmq);
> 
> I am not an expert in that side, how it interacts with the OpenCSD.
> thus left this patch as an RFC.
> 
> I appreciate your feedback and thoughts. If you feel like you could
> cleanup and implement this, please feel free to do so. Otherwise, I
> might try it out whenever I have some spare cycles to understand
> this side of the code (and this might be delayed).

You are welcome!  Sure, I will try to work out a change and share
back.

Thanks,
Leo



More information about the linux-arm-kernel mailing list