On Mon, Nov 28, 2022 at 10:36 AM Alexander Shishkin
<alexander.shishkin@xxxxxxxxxxxxxxx> wrote:
>
> Rob Herring <robh@xxxxxxxxxx> writes:
>
> > On Fri, Nov 18, 2022 at 10:49 AM Will Deacon <will@xxxxxxxxxx> 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
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
