From: Leo Yan <leo.yan@linaro.org>
To: Denis Nikitin <denik@chromium.org>
Cc: al.grant@arm.com, Anshuman Khandual <Anshuman.Khandual@arm.com>,
"coresight@lists.linaro.org" <coresight@lists.linaro.org>,
Suzuki Poulose <Suzuki.Poulose@arm.com>,
"mike.leach@linaro.org" <mike.leach@linaro.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Daniel Kiss <Daniel.Kiss@arm.com>
Subject: Re: [PATCH 3/3] rfc: perf: cs_etm: Detect pid in VMID for kernel running at EL2
Date: Wed, 23 Dec 2020 16:05:33 +0800 [thread overview]
Message-ID: <20201223080532.GA26191@leoy-ThinkPad-X240s> (raw)
In-Reply-To: <CADDJ8CVqz8Gdkx42H+TjdBOS-Vjk4MAVV7PhAaeBNq9Ejh=usA@mail.gmail.com>
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-12-23 8:07 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-10 18:33 [PATCH 0/3] coresight: etm-perf: Fix pid tracing with VHE Suzuki K Poulose
2020-11-10 18:33 ` [PATCH 1/3] coresight: etm-perf: Add support for PID tracing for kernel at EL2 Suzuki K Poulose
2020-11-12 10:27 ` Leo Yan
2020-11-12 12:41 ` Suzuki K Poulose
2020-11-10 18:33 ` [PATCH 2/3] perf: cs_etm: Use pid tracing explicitly instead of contextid Suzuki K Poulose
2020-11-12 10:00 ` Leo Yan
2020-11-12 10:54 ` Suzuki K Poulose
2020-11-12 12:24 ` Leo Yan
2020-11-10 18:33 ` [PATCH 3/3] rfc: perf: cs_etm: Detect pid in VMID for kernel running at EL2 Suzuki K Poulose
2020-11-10 22:57 ` Suzuki K Poulose
2020-11-11 11:03 ` Al Grant
2020-11-11 11:40 ` Suzuki K Poulose
2020-11-13 0:11 ` Leo Yan
2020-11-13 9:47 ` Suzuki K Poulose
2020-11-13 10:42 ` Leo Yan
2020-11-16 9:46 ` Leo Yan
2020-12-18 10:46 ` Daniel Kiss
[not found] ` <CADDJ8CVqz8Gdkx42H+TjdBOS-Vjk4MAVV7PhAaeBNq9Ejh=usA@mail.gmail.com>
2020-12-23 8:05 ` Leo Yan [this message]
2021-01-04 17:33 ` Suzuki K Poulose
2021-01-04 18:06 ` Mathieu Poirier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201223080532.GA26191@leoy-ThinkPad-X240s \
--to=leo.yan@linaro.org \
--cc=Anshuman.Khandual@arm.com \
--cc=Daniel.Kiss@arm.com \
--cc=Suzuki.Poulose@arm.com \
--cc=al.grant@arm.com \
--cc=coresight@lists.linaro.org \
--cc=denik@chromium.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mike.leach@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox