[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL_Jsq+JLcWESzGzjsmrir+gCFEO88YMYdj+FOBhjZgSBNOeVA@mail.gmail.com>
Date: Tue, 26 Oct 2021 08:34:35 -0500
From: Rob Herring <robh@...nel.org>
To: Mark Rutland <mark.rutland@....com>
Cc: Will Deacon <will@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Vince Weaver <vincent.weaver@...ne.edu>,
Honnappa Nagarahalli <honnappa.nagarahalli@....com>,
Zachary.Leaf@....com, Catalin Marinas <catalin.marinas@....com>,
Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...hat.com>,
Namhyung Kim <namhyung@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Borislav Petkov <bp@...en8.de>, X86 ML <x86@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
linux-perf-users@...r.kernel.org
Subject: Re: [PATCH v11 0/5] arm64 userspace counter support
On Tue, Oct 26, 2021 at 8:10 AM Mark Rutland <mark.rutland@....com> wrote:
>
> On Tue, Oct 19, 2021 at 06:19:02PM -0500, Rob Herring wrote:
> > Another version of arm64 userspace counter access support.
> >
> > The arm64 support departs from the x86 implementation by requiring the user
> > to explicitly request user access (via attr.config1) and only enables access
> > for task bound events. Since usage is explicitly requested, access is
> > enabled at perf_event_open() rather than on mmap() as that greatly
> > simplifies the implementation. Rather than trying to lock down the access
> > as the x86 implementation has been doing, we can start with only a limited
> > use case enabled and later expand it if needed.
> >
> > I've run this version thru Vince's perf tests[13] with arm64 support added.
> > I wish I'd found these tests sooner...
>
> When you say "with arm64 support added", do you mean with patches not
> yet upstreamed?
Correct.
> I took a look at the upstream repo, and there's some existing RDPMC
> support even though upstream never previously supported userspace
> access. That support code uses PMSELR_EL0, which this series adds no
> provisions for.
>
> Kernel-side, we'll need to either:
>
> * Document that PMSELR_EL0 is unreliable, and explcitly zero it within
> the kernel such that it cnanot be used as a covert channel. Get the
> tests updated to not rely on the never-previously-supported use of
> PMSELR_EL0.
>
> * Context switch PMSELR_EL0 (which'll IIUC is unreliable for big.LITTLE,
> even where the registers exist on each CPU).
Whether we support userspace using PMSELR_EL0 or not, we just need to
zero it when userspace access is enabled (like the dirty counters).
When there's a context switch, the read sequence is going to be
incremented and PMSELR_EL0 will need to be written to again.
Rob
Powered by blists - more mailing lists