lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 13 May 2022 12:25:16 +0000 From: Besar Wicaksono <bwicaksono@...dia.com> To: Suzuki K Poulose <suzuki.poulose@....com>, Will Deacon <will@...nel.org>, Sudeep Holla <sudeep.holla@....com> CC: "catalin.marinas@....com" <catalin.marinas@....com>, "mark.rutland@....com" <mark.rutland@....com>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>, "thanu.rangarajan@....com" <thanu.rangarajan@....com>, "Michael.Williams@....com" <Michael.Williams@....com>, Thierry Reding <treding@...dia.com>, Jonathan Hunter <jonathanh@...dia.com>, Vikram Sethi <vsethi@...dia.com>, Mathieu Poirier <mathieu.poirier@...aro.org> Subject: RE: [PATCH 0/2] perf: ARM CoreSight PMU support > -----Original Message----- > From: Besar Wicaksono > Sent: Wednesday, May 11, 2022 11:45 AM > To: Suzuki K Poulose <suzuki.poulose@....com>; Will Deacon > <will@...nel.org>; Sudeep Holla <sudeep.holla@....com> > Cc: catalin.marinas@....com; mark.rutland@....com; linux-arm- > kernel@...ts.infradead.org; linux-kernel@...r.kernel.org; linux- > tegra@...r.kernel.org; thanu.rangarajan@....com; > Michael.Williams@....com; Thierry Reding <treding@...dia.com>; Jonathan > Hunter <jonathanh@...dia.com>; Vikram Sethi <vsethi@...dia.com>; > Mathieu Poirier <mathieu.poirier@...aro.org> > Subject: RE: [PATCH 0/2] perf: ARM CoreSight PMU support > > > > > -----Original Message----- > > From: Suzuki K Poulose <suzuki.poulose@....com> > > Sent: Wednesday, May 11, 2022 3:45 AM > > To: Will Deacon <will@...nel.org>; Sudeep Holla > <sudeep.holla@....com> > > Cc: Besar Wicaksono <bwicaksono@...dia.com>; > catalin.marinas@....com; > > mark.rutland@....com; linux-arm-kernel@...ts.infradead.org; linux- > > kernel@...r.kernel.org; linux-tegra@...r.kernel.org; > > thanu.rangarajan@....com; Michael.Williams@....com; Thierry Reding > > <treding@...dia.com>; Jonathan Hunter <jonathanh@...dia.com>; Vikram > > Sethi <vsethi@...dia.com>; Mathieu Poirier <mathieu.poirier@...aro.org> > > Subject: Re: [PATCH 0/2] perf: ARM CoreSight PMU support > > > > External email: Use caution opening links or attachments > > > > > > On 10/05/2022 12:13, Will Deacon wrote: > > > On Tue, May 10, 2022 at 12:07:42PM +0100, Sudeep Holla wrote: > > >> On Mon, May 09, 2022 at 11:02:23AM +0100, Suzuki K Poulose wrote: > > >>> Cc: Mike Williams, Mathieu Poirier > > >>> On 09/05/2022 10:28, Will Deacon wrote: > > >>>> On Sun, May 08, 2022 at 07:28:08PM -0500, Besar Wicaksono wrote: > > >>>>> arch/arm64/configs/defconfig | 1 + > > >>>>> drivers/perf/Kconfig | 2 + > > >>>>> drivers/perf/Makefile | 1 + > > >>>>> drivers/perf/coresight_pmu/Kconfig | 10 + > > >>>>> drivers/perf/coresight_pmu/Makefile | 7 + > > >>>>> .../perf/coresight_pmu/arm_coresight_pmu.c | 1317 > > +++++++++++++++++ > > >>>>> .../perf/coresight_pmu/arm_coresight_pmu.h | 147 ++ > > >>>>> .../coresight_pmu/arm_coresight_pmu_nvidia.c | 300 ++++ > > >>>>> .../coresight_pmu/arm_coresight_pmu_nvidia.h | 17 + > > >>>>> 9 files changed, 1802 insertions(+) > > >>>> > > >>>> How does this interact with all the stuff we have under > > >>>> drivers/hwtracing/coresight/? > > >>> > > >>> Absolutely zero, except for the name. The standard > > >>> is named "CoreSight PMU" which is a bit unfortunate, > > >>> given the only link, AFAIU, with the "CoreSight" architecture > > >>> is the Lock Access Register(LAR). For reference, the > > >>> drivers/hwtracing/coresight/ is purely "CoreSight" self-hosted > > >>> tracing and the PMU is called "cs_etm" (expands to coresight etm). > > >>> Otherwise the standard doesn't have anything to do with what > > >>> exists already in the kernel. > > > > > > That's... a poor naming choice! But good, if it's entirely separate then I > > > don't have to worry about that. Just wanted to make sure we're not > going > > to > > > get tangled up in things like ROM tables and Coresight power domains for > > > these things. > > > > > >>> One potential recommendation for the name is, "Arm PMU" (The > ACPI > > table is > > >>> named Arm PMU Table). But then that could be clashing with the > > armv8_pmu > > >>> :-(. > > >>> > > >>> Some of the other options are : > > >>> > > >>> "Arm Generic PMU" > > >>> "Arm Uncore PMU" > > >> > > >> I wasn't sure on this if there is any restriction on usage of this on Arm > > >> and hence didn't make the suggestion. But if allowed, this would be my > > >> choice too. > > > > > > We'd taken to calling them "System" PMUS in the past, so maybe just > stick > > > with that? I think "Uncore" is Intel terminology so it's probably best to > > > > I thought about that, but there are some IPs named "System Profilers" > > (e.g., on Juno board) which could be easily confused. But I hope their > > population in the name space is much less. So, I am happy with that > > choice. The only other concern is, it doesn't indicate it supports PMUs > > that are compliant to a given Arm Standard. i.e., people could think of > > this as a "single type" of PMU. > > So, I am wondering if something like "Arm Standard PMU" makes any > sense ? > > > > Also, I hope the drivers would choose a name indicating the "type" - > > <vendor>_<type>_pmu (e.g., nvidia_pcie_pmu, arm_smmuv3_pmu etc) > > while > > registering their PMU. That way it is clearer for the PMU while the > > base device could be arm_system_pmu_0 etc. > > From the other PMU drivers, the registered name may have additional > properties > specific to the implementation, e.g. socket, cluster id, instance number, > memory > address, cache level. Since this is a shared driver, my initial thought is to > register > a default arm_coresight_pmu<APMT node id> naming format for > consistency and > "identifier" sysfs node to distinguish the PMUs. If an implementation needs > to > expose more details about the PMU, it can be communicated via additional > sysfs attributes. Hi Will and Suzuki, Shall we go ahead with "arm_system_pmu" for the device name ? > > Regards, > Besar
Powered by blists - more mailing lists