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

[John Garry]

> > > 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@xxxxxxxxxx/
> > 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