Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220825-arm-spe-v8-7-v3-0-87682f78caac@kernel.org>
 <20220825-arm-spe-v8-7-v3-7-87682f78caac@kernel.org> <20221118164943.GA4872@willie-the-truck>
 <CAL_JsqJMxEWhqZV=yqG15zvEHrBTwRVfHA6zptu2TswxRMSR0A@mail.gmail.com> <877czfujdj.fsf@ubik.fi.intel.com>
In-Reply-To: <877czfujdj.fsf@ubik.fi.intel.com>
From:   Rob Herring <robh@kernel.org>
Date:   Mon, 28 Nov 2022 11:15:21 -0600
Message-ID: <CAL_JsqKJYrEUzkzNMKMOGvzJN_EqacHZvBR6eVt35bRhhtRo=g@mail.gmail.com>
Subject: Re: [PATCH v3 7/8] perf: Add perf_event_attr::config3
To:     Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc:     Will Deacon <will@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Arnaldo Carvalho de Melo <acme@kernel.org>,
        Ingo Molnar <mingo@redhat.com>,
        Namhyung Kim <namhyung@kernel.org>,
        Jiri Olsa <jolsa@kernel.org>,
        Mark Rutland <mark.rutland@arm.com>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Marc Zyngier <maz@kernel.org>,
        Oliver Upton <oliver.upton@linux.dev>,
        Suzuki K Poulose <suzuki.poulose@arm.com>,
        James Morse <james.morse@arm.com>,
        Alexandru Elisei <alexandru.elisei@arm.com>,
        kvmarm@lists.linux.dev, linux-perf-users@vger.kernel.org,
        linux-kernel@vger.kernel.org, James Clark <james.clark@arm.com>,
        Mark Brown <broonie@kernel.org>,
        linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, Nov 28, 2022 at 10:36 AM Alexander Shishkin
<alexander.shishkin@linux.intel.com> wrote:
>
> Rob Herring <robh@kernel.org> writes:
>
> > On Fri, Nov 18, 2022 at 10:49 AM Will Deacon <will@kernel.org> wrote:
> >>
> >> On Fri, Nov 04, 2022 at 10:55:07AM -0500, Rob Herring wrote:
> >> > @@ -515,6 +516,8 @@ struct perf_event_attr {
> >> >        * truncated accordingly on 32 bit architectures.
> >> >        */
> >> >       __u64   sig_data;
> >> > +
> >> > +     __u64   config3; /* extension of config2 */
> >>
> >> I need an ack from the perf core maintainers before I can take this.
> >
> > Peter, Arnaldo, Ingo,
> >
> > Can I get an ack on this please.
>
> It appears that PMUs that don't use config{1,2} and now config3 allow
> them to be whatever without any validation, whereas in reality we should
> probably -EINVAL in those cases. Should something be done about that?

Always the 3rd occurrence that gets to clean-up things. ;)

I think we'd have to add some capability flags for PMU drivers to set
to enable configN usage and then use those to validate configN is 0.
Wouldn't be too hard to do for config3 as we know there's exactly 1
user, but for 1,2 there's about 80 PMU drivers to check.

Rob