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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 02 May 2018 10:20:19 -0400
From:   Agustin Vega-Frias <agustinv@...eaurora.org>
To:     Yisheng Xie <xieyisheng1@...wei.com>
Cc:     Neil Leeder <neil.m.leeder@...il.com>,
        Will Deacon <will.deacon@....com>,
        Mark Rutland <mark.rutland@....com>,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        Mark Langsdorf <mlangsdo@...hat.com>,
        Mark Salter <msalter@...hat.com>, Jon Masters <jcm@...hat.com>,
        Timur Tabi <timur@...eaurora.org>,
        Mark Brown <broonie@...nel.org>
Subject: Re: [PATCH 2/2] perf: add arm64 smmuv3 pmu driver

On 2018-04-02 02:37, Yisheng Xie wrote:
> Hi Neil,
> 
> On 2018/4/1 13:44, Neil Leeder wrote:
>> Hi Yisheng Xie,
>> 
>> On 3/29/2018 03:03 AM, Yisheng Xie wrote:
>>> 
>>> Hi Neil,
>>> 
>>> On 2017/8/5 3:59, Neil Leeder wrote:
>>>> +    mem_resource_0 = platform_get_resource(pdev, IORESOURCE_MEM, 
>>>> 0);
>>>> +    mem_map_0 = devm_ioremap_resource(&pdev->dev, mem_resource_0);
>>>> +
>>> Can we use devm_ioremap instead? for the reg_base of smmu_pmu is
>>> IMPLEMENTATION DEFINED. If the reg of smmu_pmu is inside smmu,
>>> devm_ioremap_resource will failed and return -EBUSY, eg.:
>>> 
>>>   smmu reg ranges:        0x180000000 ~ 0x1801fffff
>>>   its smmu_pmu reg ranges:    0x180001000 ~ 0x180001fff
>>> 
>> Just to let you know that I no longer work at Qualcomm and I won't be 
>> able to provide updates to this patchset. I expect that others from my 
>> former team at Qualcomm will pick up ownership.
> 
> Thanks for this infomation.
> 
> hi Agustin and Timur,
> 
> Is there any new status about this patchset?
> 

Hi,

Apologies for the slow response.
We are having some internal discussions about when/if to do this.
I expect to have more clarity within a few weeks.

For what is worth let me take the opportunity to outline the approach
we would like to see for a V2 either developed by us or somebody else
in the community:

1. Rework to comply with the IORT spec changes.

2. Rework probing to extract extra information from the IORT table
    about SMMU/device associations.

   With this information and some perf user space work I think it's 
possible
   to have a single dynamic PMU node and use a similar approach to what 
is
   used in the Coresight drivers to pass the device we want to monitor 
and
   for the driver to find the PMU/PMCG. E.g.:

   $ lspci
   0001:00:00.0 PCI bridge: Airgo Networks, Inc. Device 0401
   0002:00:00.0 PCI bridge: Airgo Networks, Inc. Device 0401
   0002:01:00.0 Ethernet controller: Mellanox Technologies MT27500 Family 
[ConnectX-3]
   0003:00:00.0 PCI bridge: Airgo Networks, Inc. Device 0401
   0003:01:00.0 Ethernet controller: Mellanox Technologies MT27500 Family 
[ConnectX-3]

   # Monitor TLB misses on root complex 2 (no stream filter is applied)
   perf stat -a -e smmu/tlb_miss,@0002:00:00.0/ <workload>

   # Monitor TLB misses on a device on root complex 2 (derive the stream 
number from the RID)
   perf stat -a -e smmu/tlb_miss,@0002:01:00.0/ <workload>

Thanks,
Agustín

-- 
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a 
Linux Foundation Collaborative Project.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ