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: <1cdc3c01-e8f9-fd60-da88-cc49d22fe0be@arm.com>
Date:   Tue, 2 Oct 2018 17:35:28 +0100
From:   Robin Murphy <robin.murphy@....com>
To:     Jean-Philippe Brucker <jean-philippe.brucker@....com>,
        Shameer Kolothum <shameerali.kolothum.thodi@...wei.com>,
        lorenzo.pieralisi@....com
Cc:     mark.rutland@....com, vkilari@...eaurora.org,
        neil.m.leeder@...il.com, pabba@...eaurora.org,
        john.garry@...wei.com, will.deacon@....com,
        rruigrok@...eaurora.org, linuxarm@...wei.com,
        linux-acpi@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        guohanjun@...wei.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/3] perf: add arm64 smmuv3 pmu driver

On 02/10/18 17:19, Jean-Philippe Brucker wrote:
> On 02/10/2018 15:11, Jean-Philippe Brucker wrote:
>>> +	cfgr = readl_relaxed(smmu_pmu->reg_base + SMMU_PMCG_CFGR);
> 
> Something I missed previously: when SMMU_PMCG_CFGR.SID_FILTER_TYPE is 1,
> filtering for all counters is configured by SMMU_PMCG_SMR0 and
> SMMU_PMCG_EVTYPER0 (instead of having one separate filter per counter).

Oh, I hadn't even noticed it had that mode as well...

> In that mode with your patch, if the user applies a filter to the first
> event in the list passed to perf, it will be applied to all events.
> Filter applied on any subsequent event will be ignored. Could we make
> this more explicit? Maybe in the probe print that the PMCG is
> global-filtering, and when attempting to apply a filter to something
> else than EVCNTR0, return an error?

FWIW filtering is always per-counter-group on the SMMUv2 PMU, and it's 
actually pretty straightforward to cope with - pmu->add() just needs to 
reject the event if one with an incompatible configuration is already 
scheduled, so perf core handles it much like having more events than 
counters, by rotating the mutually-exclusive sets.

Robin.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ