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 23:43:55 +0000 [thread overview] Message-ID: <CAJ9a7Vj5Yz_2pXzwSgwou2Uq3O9CZ77VWDaPbohdy0-aeJXOxA@mail.gmail.com> (raw) In-Reply-To: <20210112141458.GF18965@leoy-ThinkPad-X240s> Hi Leo, On Tue, 12 Jan 2021 at 14:15, Leo Yan <leo.yan@linaro.org> wrote: > > Hi Mike, > > On Tue, Jan 12, 2021 at 11:23:03AM +0000, Mike Leach wrote: > > 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 concern this approach is not friendly for extension; for example, > let's say IP ETM5 with defined bit 28 as CTXTID, if add a new option > for it, we need to define macro as: > > #define ETM5_OPT_CTXTID 28 > > This will result in confliction with the existed option ETM_OPT_TS > and it is hard for maintenance for options, since there have different > prefixes (like ETM_OPT_xxx, ETM4_OPT_xxx, ETM5_OPT_xxx, etc). > No it will not - we don't need a new option for CTXTID in a hypothetical ETM5 - as we use the existing one for ETM3 and map it to the correct bit, just as ETM4 does. > I'd like to take option as knob to enable or disable hardware > feature; the low level drivers should set the appropriate values for > registers based on different options. > > Furthermore, ETM driver should report error when detect any option is > not supported, I.e. ETM3 driver should report failure if user wrongly > set the option ETM_OPT_CTXTID_IN_VMID. > > > I am not suggesting re-factoring the options completely, just > > re-naming this single option to make it clear it is unique to ETM4+. > > Here I perfer Suzuki's suggestion to simply refine comments, something > like below: > > /* > * Below are bit offsets for perf options, most of them are orignally > * coming from ETMv3.5/PTM's ETMCR config bits (so far except > * ETM_OPT_CTXTID_IN_VMID is only used for ETMv4). > * > * ETMv3.5/PTM doesn't define ETMCR config bits with prefix "ETM3_" and > * directly use below macros as config bits. > */ > #define ETM_OPT_CYCACC 12 > #define ETM_OPT_CTXTID 14 > #define ETM_OPT_CTXTID_IN_VMID 15 > #define ETM_OPT_TS 28 > #define ETM_OPT_RETSTK 29 > > > 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. > > Good catch! Seems to me, this is a good example that we should > distinguish the definition between Perf options and config bits :) > > > then having an overlapping option bit - > > that appears to be valid for ETMv3 will be confusing. > > I hope the the proposed change can avoid the confusion, if have > concern, please let me know. > > Thanks a lot for suggestions, > Leo If you think that clarification via comment is better than a change of name then go ahead. Regards Mike -- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK
WARNING: multiple messages have this Message-ID (diff)
From: Mike Leach <mike.leach@linaro.org> To: Leo Yan <leo.yan@linaro.org> Cc: Mark Rutland <mark.rutland@arm.com>, Al Grant <al.grant@arm.com>, Denis Nikitin <denik@chromium.org>, Mathieu Poirier <mathieu.poirier@linaro.org>, Suzuki K Poulose <suzuki.poulose@arm.com>, Alexander Shishkin <alexander.shishkin@linux.intel.com>, Jiri Olsa <jolsa@redhat.com>, Coresight ML <coresight@lists.linaro.org>, John Garry <john.garry@huawei.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Arnaldo Carvalho de Melo <acme@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@redhat.com>, Namhyung Kim <namhyung@kernel.org>, Will Deacon <will@kernel.org>, linux-arm-kernel <linux-arm-kernel@lists.infradead.org>, Daniel Kiss <Daniel.Kiss@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 23:43:55 +0000 [thread overview] Message-ID: <CAJ9a7Vj5Yz_2pXzwSgwou2Uq3O9CZ77VWDaPbohdy0-aeJXOxA@mail.gmail.com> (raw) In-Reply-To: <20210112141458.GF18965@leoy-ThinkPad-X240s> Hi Leo, On Tue, 12 Jan 2021 at 14:15, Leo Yan <leo.yan@linaro.org> wrote: > > Hi Mike, > > On Tue, Jan 12, 2021 at 11:23:03AM +0000, Mike Leach wrote: > > 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 concern this approach is not friendly for extension; for example, > let's say IP ETM5 with defined bit 28 as CTXTID, if add a new option > for it, we need to define macro as: > > #define ETM5_OPT_CTXTID 28 > > This will result in confliction with the existed option ETM_OPT_TS > and it is hard for maintenance for options, since there have different > prefixes (like ETM_OPT_xxx, ETM4_OPT_xxx, ETM5_OPT_xxx, etc). > No it will not - we don't need a new option for CTXTID in a hypothetical ETM5 - as we use the existing one for ETM3 and map it to the correct bit, just as ETM4 does. > I'd like to take option as knob to enable or disable hardware > feature; the low level drivers should set the appropriate values for > registers based on different options. > > Furthermore, ETM driver should report error when detect any option is > not supported, I.e. ETM3 driver should report failure if user wrongly > set the option ETM_OPT_CTXTID_IN_VMID. > > > I am not suggesting re-factoring the options completely, just > > re-naming this single option to make it clear it is unique to ETM4+. > > Here I perfer Suzuki's suggestion to simply refine comments, something > like below: > > /* > * Below are bit offsets for perf options, most of them are orignally > * coming from ETMv3.5/PTM's ETMCR config bits (so far except > * ETM_OPT_CTXTID_IN_VMID is only used for ETMv4). > * > * ETMv3.5/PTM doesn't define ETMCR config bits with prefix "ETM3_" and > * directly use below macros as config bits. > */ > #define ETM_OPT_CYCACC 12 > #define ETM_OPT_CTXTID 14 > #define ETM_OPT_CTXTID_IN_VMID 15 > #define ETM_OPT_TS 28 > #define ETM_OPT_RETSTK 29 > > > 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. > > Good catch! Seems to me, this is a good example that we should > distinguish the definition between Perf options and config bits :) > > > then having an overlapping option bit - > > that appears to be valid for ETMv3 will be confusing. > > I hope the the proposed change can avoid the confusion, if have > concern, please let me know. > > Thanks a lot for suggestions, > Leo If you think that clarification via comment is better than a change of name then go ahead. Regards Mike -- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK _______________________________________________ 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:[~2021-01-13 0:55 UTC|newest] Thread overview: 74+ 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 ` 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-09 7:44 ` Leo Yan 2021-01-09 10:05 ` kernel test robot 2021-01-10 1:24 ` [PATCH] " Suzuki K Poulose 2021-01-10 1:41 ` Leo Yan 2021-01-10 22:34 ` Suzuki K Poulose 2021-01-11 0:05 ` Leo Yan 2021-01-09 11:24 ` [PATCH v1 1/7] " kernel test robot 2021-01-11 16:22 ` Mike Leach 2021-01-11 16:22 ` Mike Leach 2021-01-12 7:22 ` Leo Yan 2021-01-12 7:22 ` Leo Yan 2021-01-12 8:58 ` Leo Yan 2021-01-12 8:58 ` Leo Yan 2021-01-12 11:03 ` Suzuki K Poulose 2021-01-12 11:03 ` Suzuki K Poulose 2021-01-12 11:23 ` Mike Leach 2021-01-12 11:23 ` Mike Leach 2021-01-12 14:14 ` Leo Yan 2021-01-12 14:14 ` Leo Yan 2021-01-12 23:43 ` Mike Leach [this message] 2021-01-12 23:43 ` Mike Leach 2021-01-15 22:30 ` Mathieu Poirier 2021-01-15 22:30 ` Mathieu Poirier 2021-01-19 7:05 ` Suzuki K Poulose 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-09 7:44 ` Leo Yan 2021-01-15 22:44 ` Mathieu Poirier 2021-01-15 22:44 ` Mathieu Poirier 2021-01-19 2:32 ` Leo Yan 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-09 7:44 ` Leo Yan 2021-01-11 7:28 ` Suzuki K Poulose 2021-01-11 7:28 ` Suzuki K Poulose 2021-01-11 12:09 ` Mike Leach 2021-01-11 12:09 ` Mike Leach 2021-01-11 15:06 ` Leo Yan 2021-01-11 15:06 ` Leo Yan 2021-01-13 0:00 ` Mike Leach 2021-01-13 0:00 ` Mike Leach 2021-01-13 2:27 ` Leo Yan 2021-01-13 2:27 ` Leo Yan 2021-01-15 22:46 ` Mathieu Poirier 2021-01-15 22:46 ` Mathieu Poirier 2021-01-16 0:50 ` Leo Yan 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-09 7:44 ` Leo Yan 2021-01-11 9:45 ` Suzuki K Poulose 2021-01-11 9:45 ` Suzuki K Poulose 2021-01-11 13:12 ` Leo Yan 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-09 7:44 ` Leo Yan 2021-01-11 9:47 ` Suzuki K Poulose 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-09 7:44 ` Leo Yan 2021-01-11 9:55 ` Suzuki K Poulose 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-09 7:44 ` Leo Yan 2021-01-11 10:07 ` Suzuki K Poulose 2021-01-11 10:07 ` Suzuki K Poulose 2021-01-11 13:10 ` Leo Yan 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-11 18:16 ` Mathieu Poirier 2021-01-12 7:23 ` Leo Yan 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=CAJ9a7Vj5Yz_2pXzwSgwou2Uq3O9CZ77VWDaPbohdy0-aeJXOxA@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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.