[PATCH 3/3] rfc: perf: cs_etm: Detect pid in VMID for kernel running at EL2
Leo Yan
leo.yan at linaro.org
Wed Dec 23 03:05:33 EST 2020
Hi Denis,
On Tue, Dec 22, 2020 at 01:57:41AM -0800, Denis Nikitin wrote:
[...]
> > > Below is the drafted patch for support PID format in the metadata and
> > > I tested for "perf record" and "perf script" command and can work as
> > > expected.
> > >
> > > P.s. I uploaded the patches into the github [1] and gave some minor
> > > refactoring for your last patch "perf cs-etm: Detect pid in VMID for
> > > kernel running at EL2".
> >
> I have tested the patches on Chrome OS EL2 kernel and they worked fine for
> me.
Thanks a lot for the testing!
> Note that "perf cs-etm: Add PID format into metadata" patch breaks perf
> backward compatibility. It may cause a problem in off-target decoding if
> there is a version skew in perf.
> I saw a discussion about perf compatibility in
> https://lists.linaro.org/pipermail/coresight/2020-November/005326.html.
> I understand that perf doesn't guarantee backward compatibility but in fact
> incompatibility issues occur rarely. I think if there is an (easy) way to
> do it the compatibility breakage should be avoided.
Agreed. After reading the code and I think it's possible to do an extra
checking the length of auxtrace info structure so that can know if
the item CS_ETMV4_PID_FMT is valid or not. Thus we needs to write a
parity function of intel_pt_has() for perf cs-etm; I will try to rework
this patch.
> This is a critical fix for Chrome OS. Please let me know what you think.
So are you asking to upstream the changes to mainline kernel? You
could see this patch is owned by Suzuki and I only proposed for one
patch for perf related change.
Suzuki, could you give some update for the plan of this patch set?
I can help to prepare the perf patch based on Suzuki's plan.
Thanks,
Leo
More information about the linux-arm-kernel
mailing list