linux-kernel - Re: [PATCH v1 2/3] drivers/perf: add DesignWare PCIe PMU driver

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: <20220927110435.00005b4d@huawei.com>
Date:   Tue, 27 Sep 2022 11:04:35 +0100
From:   Jonathan Cameron <Jonathan.Cameron@...wei.com>
To:     Shuai Xue <xueshuai@...ux.alibaba.com>
CC:     Bjorn Helgaas <helgaas@...nel.org>, <will@...nel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>, <rdunlap@...radead.org>,
        <robin.murphy@....com>, <mark.rutland@....com>,
        <baolin.wang@...ux.alibaba.com>, <zhuo.song@...ux.alibaba.com>,
        <linux-pci@...r.kernel.org>
Subject: Re: [PATCH v1 2/3] drivers/perf: add DesignWare PCIe PMU driver

On Tue, 27 Sep 2022 13:13:29 +0800
Shuai Xue <xueshuai@...ux.alibaba.com> wrote:

> 在 2022/9/27 AM1:18, Bjorn Helgaas 写道:
> > On Mon, Sep 26, 2022 at 09:31:34PM +0800, Shuai Xue wrote:  
> >> 在 2022/9/23 PM11:54, Jonathan Cameron 写道:  
> >>>> I found a similar definition in arch/ia64/pci/pci.c .
> >>>>
> >>>> 	#define PCI_SAL_ADDRESS(seg, bus, devfn, reg)		\
> >>>> 	(((u64) seg << 24) | (bus << 16) | (devfn << 8) | (reg))
> >>>>
> >>>> Should we move it into a common header first?  
> >>>
> >>> Maybe. The bus, devfn, reg part is standard bdf, but I don't think
> >>> the PCI 6.0 spec defined a version with the seg in the upper bits.
> >>> I'm not sure if we want to adopt that in LInux.  
> >>
> >> I found lots of code use seg,bus,devfn,reg with format "%04x:%02x:%02x.%x",
> >> I am not quite familiar with PCIe spec. What do you think about it, Bjorn?  
> > 
> > The PCIe spec defines an address encoding for bus/device/function/reg
> > for the purposes of ECAM (PCIe r6.0, sec 7.2.2), but as far as I know,
> > it doesn't define anything similar that includes the segment.  The
> > segment is really outside the scope of PCIe because each segment is a
> > completely separate PCIe hierarchy.  
> 
> Thank you for your explanation.
> 
> > 
> > So I probably wouldn't make this a generic definition.  But if/when
> > you print things like this out, please do use the format spec you
> > mentioned above so it matches the style used elsewhere.
> >   
> 
> Agree. The print format of bus/device/function/reg is "%04x:%02x:%02x.%x",
> so I named the PMU as the same format. Then the usage flow would be:
> 
> - lspci to get the device root port in format seg/bus/device/function/reg.
> 	10:00.0 PCI bridge: Device 1ded:8000 (rev 01)
> - select its PMU name pcie_bdf_100000.
> - monitor with perf:
> 	perf stat -a -e pcie_bdf_200/Rx_PCIe_TLP_Data_Payload/

I think you probably want something in there to indicate it's an RP
and the bdf part may be redundant...

Jonathan
> 
> Bjorn and Jonathan, are you happy with this flow?
> 
> Thank you.
> 
> Best Regards,
> Shuai
>