From: Mike Leach <mike.leach@linaro.org>
To: Leo Yan <leo.yan@linaro.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
Mathieu Poirier <mathieu.poirier@linaro.org>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
John Garry <john.garry@huawei.com>, Will Deacon <will@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Mark Rutland <mark.rutland@arm.com>, Jiri Olsa <jolsa@redhat.com>,
Namhyung Kim <namhyung@kernel.org>,
Daniel Kiss <Daniel.Kiss@arm.com>,
Denis Nikitin <denik@chromium.org>,
Coresight ML <coresight@lists.linaro.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Al Grant <al.grant@arm.com>
Subject: Re: [PATCH v1 1/7] coresight: etm-perf: Add support for PID tracing for kernel at EL2
Date: Tue, 12 Jan 2021 11:23:03 +0000 [thread overview]
Message-ID: <CAJ9a7VgYt-JemRaJn_KtO-X729jo-0y0OO5hCm=tHay31Q6msw@mail.gmail.com> (raw)
In-Reply-To: <20210112085826.GC18965@leoy-ThinkPad-X240s>
Hi Leo,
On Tue, 12 Jan 2021 at 08:58, Leo Yan <leo.yan@linaro.org> wrote:
>
> Hi Mike,
>
> On Mon, Jan 11, 2021 at 04:22:39PM +0000, Mike Leach wrote:
>
> [...]
>
> > > diff --git a/include/linux/coresight-pmu.h b/include/linux/coresight-pmu.h
> > > index b0e35eec6499..927c6285ce5d 100644
> > > --- a/include/linux/coresight-pmu.h
> > > +++ b/include/linux/coresight-pmu.h
> > > @@ -11,16 +11,19 @@
> > > #define CORESIGHT_ETM_PMU_SEED 0x10
> > >
> > > /* ETMv3.5/PTM's ETMCR config bit */
> > > -#define ETM_OPT_CYCACC 12
> > > -#define ETM_OPT_CTXTID 14
> > > -#define ETM_OPT_TS 28
> > > -#define ETM_OPT_RETSTK 29
> > > +#define ETM_OPT_CYCACC 12
> > > +#define ETM_OPT_CTXTID 14
> > > +#define ETM_OPT_CTXTID_IN_VMID 15
> >
> > Minor issue here - ETMv3.x / PTM cannot trace CXTID in VMID so this
> > may better be named ETM4_OPT_CTXTID_IN_VMID, rather than be grouped
> > with the ETM3.5 options?
>
> I looked into this suggestion but found it's complex than I assumed.
> This config bits are not only used for ETMv3.x / PTM, it's also used
> as an configuration interface between user space in Perf and kernel
> drivers.
>
> For example, in the userspace, perf tool sets bit ETM_OPT_TS to enable
> timestamp [1], this is same for ETMv3 and ETMv4. In the kernel side,
> the configuration is directly used ETMv3 (in coresight-etm3x-core.c),
> but the configuration bits are converted for ETMv4 in the function
> etm4_parse_event_config() [2].
>
> So this is a historical issue, at the early period ETMv3 and ETMv4 can
> be compatible with each other for configurations, but after evoluation,
> some configs only belong to ETMv4 and cannot be applied on ETMv3
> anymore, but we still use ETMv3.5 config bits as the interface between
> kernel and userspace.
>
I was aware that etm3/ptm used these bits as both the options and the
bit values for direct writing to the ETMCR register for ETMv3, and
re-mapped to appropriate register values in ETMv4.
In the past we have re-used etmv3.5 bit definitions ETM_xxx when
appropriate, but where unique to ETM4 we have used a ETM4_xxx naming
convention.
I am not suggesting re-factoring the options completely, just
re-naming this single option to make it clear it is unique to ETM4+.
Looking at the etmv3 driver, at present it does not actually appear to
support contextid tracing - and when it does, both bits 14 and 15 will
be required to be used - as ETMCR defines these bits as ContextID
size.
Should this ever get fixed. then having an overlapping option bit -
that appears to be valid for ETMv3 will be confusing.
Regards
Mike
> I'd like suggest we use a saperate patch set to refactor the
> configuration bits, e.g. define the arbitrary configuration bits as
> interface between user space and kernel, these bits are neutral for any
> ETM version, in the kernel ETM drivers need to convert to its own
> configuration formats. For this patch, I want to keep current
> change as it is, is this okay for you?
>
> Thanks,
> Leo
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/perf/arch/arm/util/cs-etm.c?h=v5.11-rc3#n152
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/hwtracing/coresight/coresight-etm4x-core.c?h=v5.11-rc3#n422
--
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK
next prev parent reply other threads:[~2021-01-12 11:24 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-09 7:44 [PATCH v1 0/7] coresight: etm-perf: Fix pid tracing with VHE Leo Yan
2021-01-09 7:44 ` [PATCH v1 1/7] coresight: etm-perf: Add support for PID tracing for kernel at EL2 Leo Yan
2021-01-11 16:22 ` Mike Leach
2021-01-12 7:22 ` Leo Yan
2021-01-12 8:58 ` Leo Yan
2021-01-12 11:03 ` Suzuki K Poulose
2021-01-12 11:23 ` Mike Leach [this message]
2021-01-12 14:14 ` Leo Yan
2021-01-12 23:43 ` Mike Leach
2021-01-15 22:30 ` Mathieu Poirier
2021-01-19 7:05 ` Suzuki K Poulose
2021-01-09 7:44 ` [PATCH v1 2/7] perf cs_etm: Use pid tracing explicitly instead of contextid Leo Yan
2021-01-15 22:44 ` Mathieu Poirier
2021-01-19 2:32 ` Leo Yan
2021-01-09 7:44 ` [PATCH v1 3/7] perf cs-etm: Calculate per CPU metadata array size Leo Yan
2021-01-11 7:28 ` Suzuki K Poulose
2021-01-11 12:09 ` Mike Leach
2021-01-11 15:06 ` Leo Yan
2021-01-13 0:00 ` Mike Leach
2021-01-13 2:27 ` Leo Yan
2021-01-15 22:46 ` Mathieu Poirier
2021-01-16 0:50 ` Leo Yan
2021-01-09 7:44 ` [PATCH v1 4/7] perf cs-etm: Add PID format into metadata Leo Yan
2021-01-11 9:45 ` Suzuki K Poulose
2021-01-11 13:12 ` Leo Yan
2021-01-09 7:44 ` [PATCH v1 5/7] perf cs-etm: Fixup PID_FMT when it is zero Leo Yan
2021-01-11 9:47 ` Suzuki K Poulose
2021-01-09 7:44 ` [PATCH v1 6/7] perf cs-etm: Add helper cs_etm__get_pid_fmt() Leo Yan
2021-01-11 9:55 ` Suzuki K Poulose
2021-01-09 7:44 ` [PATCH v1 7/7] perf cs-etm: Detect pid in VMID for kernel running at EL2 Leo Yan
2021-01-11 10:07 ` Suzuki K Poulose
2021-01-11 13:10 ` Leo Yan
2021-01-11 18:16 ` [PATCH v1 0/7] coresight: etm-perf: Fix pid tracing with VHE Mathieu Poirier
2021-01-12 7:23 ` Leo Yan
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='CAJ9a7VgYt-JemRaJn_KtO-X729jo-0y0OO5hCm=tHay31Q6msw@mail.gmail.com' \
--to=mike.leach@linaro.org \
--cc=Daniel.Kiss@arm.com \
--cc=acme@kernel.org \
--cc=al.grant@arm.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=coresight@lists.linaro.org \
--cc=denik@chromium.org \
--cc=john.garry@huawei.com \
--cc=jolsa@redhat.com \
--cc=leo.yan@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mathieu.poirier@linaro.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.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;
as well as URLs for NNTP newsgroup(s).