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]

Date:   Wed, 19 Feb 2020 08:50:13 +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

>>
>>> 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?
> 
> Not in my mind; any instances of the same IP can have the same ID,
> regardless of which SoC they're in. Once userspace learns about
> device-foo-4000, it knows about it on all SoCs. That also means you can
> support heterogeneous instances in the same SoC.

Sure, but this device-foo-4000 naming is a concern for standardization, 
stable ABI, and perf tool support.

> 
> If a device varies so much on a SoC-by-SoC basis and or the driver has
> no idea what to expose, it could be legitimate for the PMU driver to
> expose the SoC ID as its PMU-specific ID, but I don't think we should
> make that the common/only case.

But where does the PMU driver get the SoC ID? Does it have to check DT 
machine ID, ACPI OEM ID, or SMCCC SOC ID?

I can't imagine that you really want this stuff in the kernel PMU 
drivers, but that's your call.

> 
>> 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.
> 
> For imx8, the DT compat string or additional properties on the DDRC node
> could be used to imply the id.

Fine, but it's the ACPI case which is what I am concerned about.

> 
>>> 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.
> 
> Ok, I hadn't appreciated that the PMCG did not have an ID register
> itself.
> 
> I think that the relationship between the SMMU and PMCG is a stronger
> argument against using the SOC_ID. If the PMCGs in a system are
> heterogeneous, then you must know the type of the specific instance.

Perf tool PMU events can handle that. Each PMCG PMU instance has a 
different name - the name encoding includes the HW base address, so 
always unique per system - and then so the JSON can know this and have 
events specific per instance.

> 
>> 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.
> 
> I think that might be necessary, as otherwise we're going to back
> ourselves into a corner by building what's simple now.

I appreciate what you're saying. I'll check this idea further.

Cheers,
John