linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Ian Rogers <irogers@google.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Raphael Gault <raphael.gault@arm.com>,
	Ingo Molnar <mingo@redhat.com>,
	Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>,
	Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	Namhyung Kim <namhyung@kernel.org>, Jiri Olsa <jolsa@redhat.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v3 01/10] arm64: pmu: Add hook to handle pmu-related undefined instructions
Date: Tue, 29 Sep 2020 08:46:46 -0500	[thread overview]
Message-ID: <CAL_Jsq+pNrqBN9TghXxPi2kT_T=pfMXf89diGXqo-RauuLYRuA@mail.gmail.com> (raw)
In-Reply-To: <20200928182601.GA11974@willie-the-truck>

On Mon, Sep 28, 2020 at 1:26 PM Will Deacon <will@kernel.org> wrote:
>
> On Fri, Sep 11, 2020 at 03:51:09PM -0600, Rob Herring wrote:
> > From: Raphael Gault <raphael.gault@arm.com>
> >
> > This patch introduces a protection for the userspace processes which are
> > trying to access the registers from the pmu registers on a big.LITTLE
> > environment. It introduces a hook to handle undefined instructions.
> >
> > The goal here is to prevent the process to be interrupted by a signal
> > when the error is caused by the task being scheduled while accessing
> > a counter, causing the counter access to be invalid. As we are not able
> > to know efficiently the number of counters available physically on both
> > pmu in that context we consider that any faulting access to a counter
> > which is architecturally correct should not cause a SIGILL signal if
> > the permissions are set accordingly.
> >
> > This commit also modifies the mask of the mrs_hook declared in
> > arch/arm64/kernel/cpufeatures.c which emulates only feature register
> > access. This is necessary because this hook's mask was too large and
> > thus masking any mrs instruction, even if not related to the emulated
> > registers which made the pmu emulation inefficient.
> >
> > Signed-off-by: Raphael Gault <raphael.gault@arm.com>
> > Signed-off-by: Rob Herring <robh@kernel.org>
> > ---
> > v2:
> >  - Fix warning for set but unused sys_reg
> > ---
> >  arch/arm64/kernel/cpufeature.c |  4 +--
> >  arch/arm64/kernel/perf_event.c | 54 ++++++++++++++++++++++++++++++++++
> >  2 files changed, 56 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> > index a389b999482e..00bf53ffd9b0 100644
> > --- a/arch/arm64/kernel/cpufeature.c
> > +++ b/arch/arm64/kernel/cpufeature.c
> > @@ -2811,8 +2811,8 @@ static int emulate_mrs(struct pt_regs *regs, u32 insn)
> >  }
> >
> >  static struct undef_hook mrs_hook = {
> > -     .instr_mask = 0xfff00000,
> > -     .instr_val  = 0xd5300000,
> > +     .instr_mask = 0xffff0000,
> > +     .instr_val  = 0xd5380000,
> >       .pstate_mask = PSR_AA32_MODE_MASK,
> >       .pstate_val = PSR_MODE_EL0t,
> >       .fn = emulate_mrs,
> > diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
> > index 462f9a9cc44b..70538ae684da 100644
> > --- a/arch/arm64/kernel/perf_event.c
> > +++ b/arch/arm64/kernel/perf_event.c
> > @@ -8,9 +8,11 @@
> >   * This code is based heavily on the ARMv7 perf event code.
> >   */
> >
> > +#include <asm/cpu.h>
> >  #include <asm/irq_regs.h>
> >  #include <asm/perf_event.h>
> >  #include <asm/sysreg.h>
> > +#include <asm/traps.h>
> >  #include <asm/virt.h>
> >
> >  #include <clocksource/arm_arch_timer.h>
> > @@ -1016,6 +1018,58 @@ static int armv8pmu_probe_pmu(struct arm_pmu *cpu_pmu)
> >       return probe.present ? 0 : -ENODEV;
> >  }
> >
> > +static int emulate_pmu(struct pt_regs *regs, u32 insn)
> > +{
> > +     u32 rt;
> > +     u32 pmuserenr;
> > +
> > +     rt = aarch64_insn_decode_register(AARCH64_INSN_REGTYPE_RT, insn);
> > +     pmuserenr = read_sysreg(pmuserenr_el0);
> > +
> > +     if ((pmuserenr & (ARMV8_PMU_USERENR_ER|ARMV8_PMU_USERENR_CR)) !=
> > +         (ARMV8_PMU_USERENR_ER|ARMV8_PMU_USERENR_CR))
> > +             return -EINVAL;
> > +
> > +
> > +     /*
> > +      * Userspace is expected to only use this in the context of the scheme
> > +      * described in the struct perf_event_mmap_page comments.
> > +      *
> > +      * Given that context, we can only get here if we got migrated between
> > +      * getting the register index and doing the MSR read.  This in turn
> > +      * implies we'll fail the sequence and retry, so any value returned is
> > +      * 'good', all we need is to be non-fatal.
> > +      *
> > +      * The choice of the value 0 is comming from the fact that when
> > +      * accessing a register which is not counting events but is accessible,
> > +      * we get 0.
> > +      */
> > +     pt_regs_write_reg(regs, rt, 0);
>
> Hmm... this feels pretty fragile since, although we may expect userspace only
> to trigger this in the context of the specific perf use-case, we don't have
> a way to detect that, so the ABI we're exposing is that EL0 accesses to
> non-existent counters will return 0. I don't really think that's something
> we want to commit to.
>
> When restartable sequences were added to the kernel, one of the proposed
> use-cases was to allow PMU access on big/little systems, because the
> sequence will abort on preemption. Taking that approach removes the need
> for this emulation hook entirely. Is that something we can rely on instead
> of this emulation hook?

So back to the RFC version[1]!? That would mean pulling librseq into
the kernel based on the prior discussion. It doesn't look like that
has happened yet.

Why not just drop the undef hook? For heterogeneous systems, we
require userspace to pin itself to cores for a specific PMU. See patch
9. If userspace fails to do that, then it gets to keep the pieces.

Rob

[1] https://lore.kernel.org/linux-arm-kernel/20190625134117.r3gysn7mvzzdrytj@willie-the-truck/

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-09-29 13:48 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-11 21:51 [PATCH v3 0/10] libperf and arm64 userspace counter access support Rob Herring
2020-09-11 21:51 ` [PATCH v3 01/10] arm64: pmu: Add hook to handle pmu-related undefined instructions Rob Herring
2020-09-28 18:26   ` Will Deacon
2020-09-29 13:46     ` Rob Herring [this message]
2020-09-29 17:49       ` Will Deacon
2020-09-29 20:46         ` Rob Herring
2020-09-11 21:51 ` [PATCH v3 02/10] arm64: pmu: Add function implementation to update event index in userpage Rob Herring
2020-09-11 21:51 ` [PATCH v3 03/10] arm64: perf: Enable pmu counter direct access for perf event on armv8 Rob Herring
2020-09-11 21:51 ` [PATCH v3 04/10] tools/include: Add an initial math64.h Rob Herring
2020-09-11 21:51 ` [PATCH v3 05/10] libperf: Add libperf_evsel__mmap() Rob Herring
2020-09-18 14:33   ` Jiri Olsa
2020-09-22 15:28     ` Rob Herring
2020-09-22 18:32       ` Jiri Olsa
2020-09-11 21:51 ` [PATCH v3 06/10] libperf: tests: Add support for verbose printing Rob Herring
2020-09-11 21:51 ` [PATCH v3 07/10] libperf: Add support for user space counter access Rob Herring
2020-09-11 21:51 ` [PATCH v3 08/10] libperf: Add arm64 support to perf_mmap__read_self() Rob Herring
2020-09-11 21:51 ` [PATCH v3 09/10] perf: arm64: Add test for userspace counter access on heterogeneous systems Rob Herring
2020-09-11 21:51 ` [PATCH v3 10/10] Documentation: arm64: Document PMU counters access from userspace Rob Herring
2020-09-12 20:53 ` [PATCH v3 0/10] libperf and arm64 userspace counter access support Jiri Olsa
2020-09-14 14:21   ` Rob Herring
     [not found]     ` <CANW9uytmafiNb_8oua9QY7L9O5BQTBFQBOMS3ZgjQ7aWj8CD2Q@mail.gmail.com>
2020-09-16  2:50       ` Rob Herring
2020-09-19  7:22         ` Itaru Kitayama
2020-09-22 15:23           ` Rob Herring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAL_Jsq+pNrqBN9TghXxPi2kT_T=pfMXf89diGXqo-RauuLYRuA@mail.gmail.com' \
    --to=robh@kernel.org \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=catalin.marinas@arm.com \
    --cc=honnappa.nagarahalli@arm.com \
    --cc=irogers@google.com \
    --cc=jolsa@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=raphael.gault@arm.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).