All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Daniel Henrique Barboza <danielhb413@gmail.com>
Cc: richard.henderson@linaro.org, qemu-devel@nongnu.org,
	groug@kaod.org, qemu-ppc@nongnu.org, clg@kaod.org,
	matheus.ferst@eldorado.org.br
Subject: Re: [PATCH v3 02/15] target/ppc: add user write access control for PMU SPRs
Date: Mon, 27 Sep 2021 15:08:34 +1000	[thread overview]
Message-ID: <YVFR0kOUJ2yA6+hg@yekko> (raw)
In-Reply-To: <587d197b-25a4-c5c2-3c3c-4132ac4cdf6b@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 6070 bytes --]

On Thu, Sep 23, 2021 at 11:39:14AM -0300, Daniel Henrique Barboza wrote:
> 
> 
> On 9/6/21 22:38, David Gibson wrote:
> > On Fri, Sep 03, 2021 at 05:31:03PM -0300, Daniel Henrique Barboza wrote:
> > > The PMU needs to enable writing of its uregs to userspace, otherwise
> > > Perf applications will not able to setup the counters correctly. This
> > > patch enables user space writing of all PMU uregs.
> > > 
> > > MMCR0 is a special case because its userspace writing access is controlled
> > > by MMCR0_PMCC bits. There are 4 configurations available (0b00, 0b01,
> > > 0b10 and 0b11) but for our purposes here we're handling only
> > > MMCR0_PMCC = 0b00. In this case, if userspace tries to write MMCR0, a
> > > hypervisor emulation assistance interrupt occurs.
> > > 
> > > This is being done by adding HFLAGS_PMCCCLEAR to hflags. This flag
> > > indicates if MMCR0_PMCC is cleared (0b00), and a new 'pmcc_clear' flag in
> > > DisasContext allow us to use it in spr_write_MMCR0_ureg().
> > > 
> > > Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
> > > ---
> > >   target/ppc/cpu.h         |  1 +
> > >   target/ppc/cpu_init.c    | 18 +++++++-------
> > >   target/ppc/helper_regs.c |  3 +++
> > >   target/ppc/spr_tcg.h     |  3 ++-
> > >   target/ppc/translate.c   | 53 +++++++++++++++++++++++++++++++++++++++-
> > >   5 files changed, 67 insertions(+), 11 deletions(-)
> > > 
> > > diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h
> > > index f68bb8d8aa..8dfbb62022 100644
> > > --- a/target/ppc/cpu.h
> > > +++ b/target/ppc/cpu.h
> > > @@ -616,6 +616,7 @@ enum {
> > >       HFLAGS_SE = 10,  /* MSR_SE -- from elsewhere on embedded ppc */
> > >       HFLAGS_FP = 13,  /* MSR_FP */
> > >       HFLAGS_PR = 14,  /* MSR_PR */
> > > +    HFLAGS_PMCCCLEAR = 15, /* PMU MMCR0 PMCC equal to 0b00 */
> > >       HFLAGS_VSX = 23, /* MSR_VSX if cpu has VSX */
> > >       HFLAGS_VR = 25,  /* MSR_VR if cpu has VRE */
> > > diff --git a/target/ppc/cpu_init.c b/target/ppc/cpu_init.c
> > > index 9efc6c2d87..bb5ea04c61 100644
> > > --- a/target/ppc/cpu_init.c
> > > +++ b/target/ppc/cpu_init.c
> > > @@ -6867,7 +6867,7 @@ static void register_book3s_pmu_sup_sprs(CPUPPCState *env)
> > >   static void register_book3s_pmu_user_sprs(CPUPPCState *env)
> > >   {
> > >       spr_register(env, SPR_POWER_UMMCR0, "UMMCR0",
> > > -                 &spr_read_MMCR0_ureg, SPR_NOACCESS,
> > > +                 &spr_read_MMCR0_ureg, &spr_write_MMCR0_ureg,
> > >                    &spr_read_ureg, &spr_write_ureg,
> > >                    0x00000000);
> > >       spr_register(env, SPR_POWER_UMMCR1, "UMMCR1",
> > > @@ -6875,31 +6875,31 @@ static void register_book3s_pmu_user_sprs(CPUPPCState *env)
> > >                    &spr_read_ureg, &spr_write_ureg,
> > >                    0x00000000);
> > >       spr_register(env, SPR_POWER_UMMCRA, "UMMCRA",
> > > -                 &spr_read_ureg, SPR_NOACCESS,
> > > +                 &spr_read_ureg, &spr_write_ureg,
> > >                    &spr_read_ureg, &spr_write_ureg,
> > >                    0x00000000);
> > >       spr_register(env, SPR_POWER_UPMC1, "UPMC1",
> > > -                 &spr_read_ureg, SPR_NOACCESS,
> > > +                 &spr_read_ureg, &spr_write_ureg,
> > 
> > Surely this can't be write.  AFAICT spr_write_ureg() will
> > unconditionally allow full userspace write access.  That can't be
> > right - otherwise the OS could never safely use the PMU for itself.
> 
> My assumption here was that the user mode SPRs (UMMCR* and UPMC*) were created to
> allow userspace read/write of PMU regs, while the regular regs (MMCR* and PMC*)
> are the supermode privileged SPRs that can't be written by userspace. At least this
> is my understanding from reading commit fd51ff6328e3d98158 that introduced these
> userspace PMC regs.

Sure, but my point is that these registers are only userspace
accessible under certain conditions, IIUC.  spr_write_ureg() doesn't
test for those conditions, so it will *always* allow write access.

> The reason why these are marked as SPR_NOACCESS is because we didn't bothered
> writing into them from userspace because we had no PMU logic to work
> with.

[snip]
> > > diff --git a/target/ppc/translate.c b/target/ppc/translate.c
> > > index b2ead144d1..0babde3131 100644
> > > --- a/target/ppc/translate.c
> > > +++ b/target/ppc/translate.c
> > > @@ -175,6 +175,7 @@ struct DisasContext {
> > >       bool spe_enabled;
> > >       bool tm_enabled;
> > >       bool gtse;
> > > +    bool pmcc_clear;
> > >       ppc_spr_t *spr_cb; /* Needed to check rights for mfspr/mtspr */
> > >       int singlestep_enabled;
> > >       uint32_t flags;
> > > @@ -561,7 +562,56 @@ void spr_write_ureg(DisasContext *ctx, int sprn, int gprn)
> > >   {
> > >       gen_store_spr(sprn + 0x10, cpu_gpr[gprn]);
> > >   }
> > > -#endif
> > > +
> > > +void spr_write_MMCR0_ureg(DisasContext *ctx, int sprn, int gprn)
> > 
> > 
> > Could you put this def in the PMU specific file, rather than the
> > enormous translate.c?
> 
> Moving into the existing power8_pmu.c helper is annoying because, being a helper file,
> there is no access to the whole DisasContext declaration (that is open coded in
> translate.c), and other internal translate.c data like cpu_grp[].

Ah, right.  We should probably make that easier someday, but it's not
reasonbly in scope for this series.

> What I was able to do is create a new file in the target/ppc/translate/ dir,
> power8-pmu-regs.c.impl, and moved all these declarations over there. At very least we're
> not overloading translate.c.

Ah, nice.

> Eldorado, is that ok with you guys? I'm aware that this dir was holding new
> decode-tree insns implementations but, in this case, it would hold old format
> spr_read/spr_write code.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2021-09-27  5:12 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-03 20:31 [PATCH v3 00/15] PMU-EBB support for PPC64 TCG Daniel Henrique Barboza
2021-09-03 20:31 ` [PATCH v3 01/15] target/ppc: add user read functions for MMCR0 and MMCR2 Daniel Henrique Barboza
2021-09-07  1:27   ` David Gibson
2021-09-22 11:23   ` Matheus K. Ferst
2021-09-22 21:10     ` Daniel Henrique Barboza
2021-09-03 20:31 ` [PATCH v3 02/15] target/ppc: add user write access control for PMU SPRs Daniel Henrique Barboza
2021-09-07  1:38   ` David Gibson
2021-09-23 14:39     ` Daniel Henrique Barboza
2021-09-27  5:08       ` David Gibson [this message]
2021-09-27 23:05         ` Daniel Henrique Barboza
2021-10-07  1:17           ` David Gibson
2021-09-03 20:31 ` [PATCH v3 03/15] target/ppc: PMU basic cycle count for pseries TCG Daniel Henrique Barboza
2021-09-07  1:48   ` David Gibson
2021-09-22 11:24   ` Matheus K. Ferst
2021-09-24 14:41     ` Daniel Henrique Barboza
2021-09-24 18:34       ` Matheus K. Ferst
2021-09-24 19:05         ` Daniel Henrique Barboza
2021-09-27  5:04           ` David Gibson
2021-09-03 20:31 ` [PATCH v3 04/15] target/ppc/power8_pmu.c: enable PMC1-PMC4 events Daniel Henrique Barboza
2021-09-07  1:50   ` David Gibson
2021-09-03 20:31 ` [PATCH v3 05/15] target/ppc: PMU: add instruction counting Daniel Henrique Barboza
2021-09-07  1:57   ` David Gibson
2021-09-21 21:11     ` Daniel Henrique Barboza
2021-09-27  4:59       ` David Gibson
2021-09-03 20:31 ` [PATCH v3 06/15] target/ppc/power8_pmu.c: add PM_RUN_INST_CMPL (0xFA) event Daniel Henrique Barboza
2021-09-03 20:31 ` [PATCH v3 07/15] target/ppc/power8_pmu.c: add PMC14/PMC56 counter freeze bits Daniel Henrique Barboza
2021-09-03 20:31 ` [PATCH v3 08/15] PPC64/TCG: Implement 'rfebb' instruction Daniel Henrique Barboza
2021-09-09 11:47   ` Matheus K. Ferst
2021-09-22 19:41     ` Daniel Henrique Barboza
2021-09-03 20:31 ` [PATCH v3 09/15] target/ppc: PMU Event-Based exception support Daniel Henrique Barboza
2021-09-03 20:31 ` [PATCH v3 10/15] target/ppc/excp_helper.c: EBB handling adjustments Daniel Henrique Barboza
2021-09-03 20:31 ` [PATCH v3 11/15] target/ppc/power8_pmu.c: enable PMC1 counter negative overflow Daniel Henrique Barboza
2021-09-03 20:31 ` [PATCH v3 12/15] target/ppc/power8_pmu.c: cycles overflow with all PMCs Daniel Henrique Barboza
2021-09-03 20:31 ` [PATCH v3 13/15] target/ppc: PMU: insns counter negative overflow support Daniel Henrique Barboza
2021-09-03 20:31 ` [PATCH v3 14/15] target/ppc/translate: PMU: handle setting of PMCs while running Daniel Henrique Barboza
2021-09-03 20:31 ` [PATCH v3 15/15] target/ppc/power8_pmu.c: handle overflow bits when PMU is running Daniel Henrique Barboza

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=YVFR0kOUJ2yA6+hg@yekko \
    --to=david@gibson.dropbear.id.au \
    --cc=clg@kaod.org \
    --cc=danielhb413@gmail.com \
    --cc=groug@kaod.org \
    --cc=matheus.ferst@eldorado.org.br \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=richard.henderson@linaro.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.