[PATCH v2 3/4] perf: add arm64 smmuv3 pmu driver

[john.garry@huawei.com (John Garry)]

On 18/09/2018 13:16, Robin Murphy wrote:
> On 18/09/18 12:47, Will Deacon wrote:
>> On Mon, Sep 17, 2018 at 06:10:05PM +0100, John Garry wrote:
>>>
>>>>> +
>>>>> +#define SMMU_EVENT_ATTR(_name, _id)                      \
>>>>> +    (&((struct perf_pmu_events_attr[]) {                  \
>>>>> +        { .attr = __ATTR(_name, 0444, smmu_pmu_event_show, NULL), \
>>>>> +          .id = _id, }                          \
>>>>> +    })[0].attr.attr)
>>>>> +
>>>>> +static struct attribute *smmu_pmu_events[] = {
>>>>> +    SMMU_EVENT_ATTR(cycles, SMMU_PMU_CYCLES),
>>>>> +    SMMU_EVENT_ATTR(transaction, SMMU_PMU_TRANSACTION),
>>>>> +    SMMU_EVENT_ATTR(tlb_miss, SMMU_PMU_TLB_MISS),
>>>>> +    SMMU_EVENT_ATTR(config_cache_miss, SMMU_PMU_CONFIG_CACHE_MISS),
>>>>> +    SMMU_EVENT_ATTR(trans_table_walk, SMMU_PMU_TRANS_TABLE_WALK),
>>>>> +    SMMU_EVENT_ATTR(config_struct_access,
>>>>> SMMU_PMU_CONFIG_STRUCT_ACCESS),
>>>>> +    SMMU_EVENT_ATTR(pcie_ats_trans_rq, SMMU_PMU_PCIE_ATS_TRANS_RQ),
>>>>> +    SMMU_EVENT_ATTR(pcie_ats_trans_passed,
>>>>> SMMU_PMU_PCIE_ATS_TRANS_PASSED),
>>>>> +    NULL
>>>>> +};
>>>>> +
>>>>> +static umode_t smmu_pmu_event_is_visible(struct kobject *kobj,
>>>>> +                     struct attribute *attr, int unused)
>>>>> +{
>>>>> +    struct device *dev = kobj_to_dev(kobj);
>>>>> +    struct smmu_pmu *smmu_pmu = to_smmu_pmu(dev_get_drvdata(dev));
>>>>> +    struct perf_pmu_events_attr *pmu_attr;
>>>>> +
>>>>> +    pmu_attr = container_of(attr, struct perf_pmu_events_attr,
>>>>> attr.attr);
>>>>> +
>>>>> +    if (test_bit(pmu_attr->id, smmu_pmu->supported_events))
>>>>> +        return attr->mode;
>>>>> +
>>>>> +    return 0;
>>>>> +}
>>>>> +static struct attribute_group smmu_pmu_events_group = {
>>>>> +    .name = "events",
>>>>> +    .attrs = smmu_pmu_events,
>>>>> +    .is_visible = smmu_pmu_event_is_visible,
>>>>> +};
>>>>> +
>>>>> +/* Formats */
>>>>> +PMU_FORMAT_ATTR(event,           "config:0-15");
>>>>> +PMU_FORMAT_ATTR(filter_stream_id,  "config1:0-31");
>>>>> +PMU_FORMAT_ATTR(filter_span,       "config1:32");
>>>>> +PMU_FORMAT_ATTR(filter_enable,       "config1:33");
>>>>> +
>>>>> +static struct attribute *smmu_pmu_formats[] = {
>>>>> +    &format_attr_event.attr,
>>>>> +    &format_attr_filter_stream_id.attr,
>>>>> +    &format_attr_filter_span.attr,
>>>>> +    &format_attr_filter_enable.attr,
>>>>> +    NULL
>>>>> +};
>>>>> +
>>>>> +static struct attribute_group smmu_pmu_format_group = {
>>>>> +    .name = "format",
>>>>> +    .attrs = smmu_pmu_formats,
>>>>> +};
>>>>> +
>>>>> +static const struct attribute_group *smmu_pmu_attr_grps[] = {
>>>>> +    &smmu_pmu_cpumask_group,
>>>>> +    &smmu_pmu_events_group,
>>>>> +    &smmu_pmu_format_group,
>>>>> +    NULL,
>>>>> +};
>>>>> +
>>>
>>>
>>> Question: If we wanted to add proper named event support for the
>>> IMPLEMENTATION DEFINED events, how to add (if at all)?
>>>
>>> So currently the driver only supports the Architected events, which
>>> is fine.
>>> And we support raw events for the IMPLEMENTATION DEFINED events
>>> (0x80-0xFFFF).
>>>
>>> But to add named event support for the IMP DEF events, I assume we would
>>> want to do something similar to arm64 CPU PMU events - that is, common
>>> architected events in kernel pmu driver, and implementation defined
>>> events
>>> defined in perf tool. However I don't know if it's even feasible
>>> considering
>>> there does not seem to be a mandatory/standard PMCG ID register to
>>> detect
>>> the implementation.
>>
>> I guess we'd need something from firmware to identify the SMMU/PMU
>> implementation, so that we could probe the driver correctly. Once we have
>> that, it seems like it's just a matter of exposing a different name to
>> userspace, like we do for the CPU PMU.
>
> Indeed - in fact a while ago I raised it with the architects that PMCGs
> don't have an equivalent to IIDR, so you can't interpret the imp-def
> PMCG_ID_REGS without already knowing what the thing is some other way.
> For IORT it should already be somewhat feasible to figure out the
> implementation by way of chasing the node reference to figure out what
> device the the PMCG is part of, however that might require some sort of
> API between the PMCG driver and SMMUv3 (and other component) driver(s)
> to communicate runtime-probed stuff.
>

OK, so it should be feasiable to achieve this by knowing the associated 
SMMUv3, but seems a bit painful to support in software.

Thanks,
John

> Robin.
>
> .
>