linux-kernel - RE: [PATCH 0/2] perf: ARM CoreSight PMU support

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
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <SJ0PR12MB567658E8F744F151278D9431A0CA9@SJ0PR12MB5676.namprd12.prod.outlook.com>
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