linux-kernel - Re: [PATCH RFC 0/7] perf pmu-events: Support event aliasing for system PMUs

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: <cb004f43-b2a4-ae23-9fd3-0f70bd69701b@huawei.com>
Date:   Tue, 18 Feb 2020 17:58:46 +0000
From:   John Garry <john.garry@...wei.com>
To:     Mark Rutland <mark.rutland@....com>
CC:     "ak@...ux.intel.com" <ak@...ux.intel.com>,
        Joakim Zhang <qiangqing.zhang@....com>,
        "suzuki.poulose@....com" <suzuki.poulose@....com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        Will Deacon <will@...nel.org>, Linuxarm <linuxarm@...wei.com>,
        "acme@...nel.org" <acme@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Zhangshaokun <zhangshaokun@...ilicon.com>,
        "alexander.shishkin@...ux.intel.com" 
        <alexander.shishkin@...ux.intel.com>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "james.clark@....com" <james.clark@....com>,
        "namhyung@...nel.org" <namhyung@...nel.org>,
        "jolsa@...hat.com" <jolsa@...hat.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "robin.murphy@....com" <robin.murphy@....com>,
        Sudeep Holla <sudeep.holla@....com>
Subject: Re: [PATCH RFC 0/7] perf pmu-events: Support event aliasing for
 system PMUs

On 18/02/2020 17:08, Mark Rutland wrote:
>>> I also don't understand how a SoC ID makes things
>>> any easier in this regard.
>> It's doesn't necessarily make things easier in this regard. But using a SoC
>> ID is an alternative to checking the SMMU_ID or the kernel driver having to
>> know that it was a MMU-600 at all.
> Using SOC_ID means that going forward, userspace needs to learn about
> the integration details of each SoC in order to identify a component. As
> you said:
> 
> | As constantly checking what the SoC ID means throughout system components
> | does not scale.
> 
> ... and I think that equally applies to userspace in this case. Who knows how
> many SoCs are going to have MMU-600?
> 
> I also know that SOC_ID is going to be optional, and I think it's near-certain
> that someone will end up producing two SoCs exposing the same ID.

Wouldn't different SoCs having same SMC SOC_ID and revision be a 
(fixable) mistake in the SMC FW?

And if it's not implemented, then no PMU events aliasing in perf tool 
for those uncore PMUs - nothing gets broken though and no regression. 
But I do understand your concern here.

> 
> For system PMUs, I'd rather the system PMU driver exposed some sort of
> implementation ID. e.g. the SMMU_ID for SMMU. We can give that a generic name,
> and mandate that where a driver exposes it, the format/meaning is defined in
> the documentation for the driver.

Then doesn't that per-PMU ID qualify as brittle and non-standard also?

At least the SMC SoC ID is according to some standard.

And typically most PMU HW would have no ID reg, so where to even get 
this identification info? Joakim Zhang seems to have this problem for 
the imx8 DDRC PMU driver.

> 
> That can be namespace by driver, so e.g. keys would be smmu_sysfs_name/<id> and
> ddrc_sysfs_name/<id>.
> 
>>>> So even if it is solvable here, the kernel driver(s) will need to be
>>>> reworked. And that is just solving one case in many.
>>> PMU drivers will need to expose more information to userspace so that they
>>> can be identified more precisely, yes. I wouldn't say they would need to be
>>> "reworked".
>> OK, so some combination of changes would still be required for the SMMU
>> PMCG, IORT, and SMMUv3 drivers.
> To expose the SMMU ID, surely that's just the driver? 

This case is complicated, like others I anticipate.

So the SMMU PMCG HW has no ID register itself, and this idea relies on 
using the associated SMMUv3 IIDR in lieu. For that, we need to involve 
the IORT, SMMUv3, and SMMU PMCG drivers to create this linkage, and even 
then I still have my doubts on whether this is even proper.

Please see 
https://lore.kernel.org/linux-iommu/1569854031-237636-1-git-send-email-john.garry@huawei.com/ 
for reference.

Or are there
> implementations where the ID register is bogus and have to be overridden?
> 

I will also note that perf tool PMU events framework relies today on 
generating a table of events aliases per CPU and matching based on that. 
If you want to totally disassociate a CPU or any SoC ID mapping, then 
this will require big perf tool rework.

Thanks,
John