qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Aaron Lindsay <aaron@os.amperecomputing.com>
To: Richard Henderson <richard.henderson@linaro.org>
Cc: "qemu-arm@nongnu.org" <qemu-arm@nongnu.org>,
	Peter Maydell <peter.maydell@linaro.org>,
	Alistair Francis <alistair.francis@xilinx.com>,
	Wei Huang <wei@redhat.com>,
	Peter Crosthwaite <crosthwaite.peter@gmail.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Michael Spradling <mspradli@codeaurora.org>,
	Digant Desai <digantd@codeaurora.org>,
	Aaron Lindsay <alindsay@codeaurora.org>
Subject: Re: [Qemu-devel] [PATCH v10 14/14] target/arm: Send interrupts on PMU counter overflow
Date: Fri, 18 Jan 2019 21:40:55 +0000	[thread overview]
Message-ID: <20190118214052.GD5213@quinoa.localdomain> (raw)
In-Reply-To: <8683c2c4-0111-492c-c6f9-1b2dcc937405@linaro.org>

On Jan 18 07:26, Richard Henderson wrote:
> On 12/12/18 2:20 AM, Aaron Lindsay wrote:
> > Setup a QEMUTimer to get a callback when we expect counters to next
> > overflow and trigger an interrupt at that time.
> > 
> > Signed-off-by: Aaron Lindsay <alindsay@codeaurora.org>
> > Signed-off-by: Aaron Lindsay <aaron@os.amperecomputing.com>
> > ---
> >  target/arm/cpu.c    |  12 +++++
> >  target/arm/cpu.h    |   8 +++
> >  target/arm/helper.c | 126 +++++++++++++++++++++++++++++++++++++++++---
> >  3 files changed, 140 insertions(+), 6 deletions(-)
> 
> Well, this patch is doing several things at once -- adding the timer, adding
> the ns_per_count hook, updating irqs.  Not ideal, but I won't insist it be split.
> 
> You'll need to re-run against scripts/checkpatch, it would seem.
> The goal-posts with respect to comments have been changed since
> you started this.

Okay, I'll check that again before I send the next version out.

> > @@ -1305,7 +1338,19 @@ void pmccntr_op_start(CPUARMState *env)
> >              eff_cycles /= 64;
> >          }
> >  
> > -        env->cp15.c15_ccnt = eff_cycles - env->cp15.c15_ccnt_delta;
> > +        uint64_t new_pmccntr = eff_cycles - env->cp15.c15_ccnt_delta;
> > +
> > +        unsigned int overflow_bit = (env->cp15.c9_pmcr & PMCRLC) ? 63 : 31;
> > +        uint64_t overflow_mask = (uint64_t)1 << overflow_bit;
> 
> Could just as easily be
> 
>   uint64_t overflow_mask = env->cp15.c9_pmcr & PMCRLC ? INT64_MIN : INT32_MIN;

Updated.

> > +        if (env->cp15.c15_ccnt & ~new_pmccntr & overflow_mask) {
> > +            env->cp15.c9_pmovsr |= (1 << 31);
> > +            if (!(env->cp15.c9_pmcr & PMCRLC)) {
> > +                new_pmccntr &= 0xffffffff;
> > +            }
> 
> Why is this truncation buried within the overflow condition?  Simply because
> the high bits can't be set without overflow being noticed?  That could use a
> comment, because it looks odd.

Upon re-reading the spec, I don't think this is needed (or even correct
behavior). I must've been thinking that PMCR.LC == 0 implied that upper
32 bits could never be updated by the hardware and made PMCCNTR act like
its high bits didn't even exist, like one of the PMXEVCNTRs. I no longer
believe that is true and I'll remove this.

> > @@ -1340,8 +1399,15 @@ static void pmevcntr_op_start(CPUARMState *env, uint8_t counter)
> >      }
> >  
> >      if (pmu_counter_enabled(env, counter)) {
> > -        env->cp15.c14_pmevcntr[counter] =
> > -            count - env->cp15.c14_pmevcntr_delta[counter];
> > +        uint64_t new_pmevcntr = count - env->cp15.c14_pmevcntr_delta[counter];
> > +
> > +        if (!(new_pmevcntr & PMEVCNTR_OVERFLOW_MASK) &&
> > +                (env->cp15.c14_pmevcntr[counter] & PMEVCNTR_OVERFLOW_MASK)) {
> > +            env->cp15.c9_pmovsr |= (1 << counter);
> > +            new_pmevcntr &= ~PMEVCNTR_OVERFLOW_MASK;
> 
> That, surely, does not do what you intend.  I can only imagine that you meant
> 
>     new_pmevcntr = (uint32_t)new_pmevcntr;
> or
>     new_pmevcntr &= PMEVCNTR_OVERFLOW_MASK - 1;
> 
> depending on how much you want to depend on the symbol defining the width.

In practice, I think only the 32nd bit would ever need to be cleared,
but I agree it is more correct to clear them all.

> Given that it is architecturally defined to 32-bits, I think you could really
> just drop the define and use
> 
>     uint32_t new_pmevcntr = ...;
>     if (env->cp15.c14_pmevcntr[counter] & ~new_pmevcntr & INT32_MIN)
>
> with equal clarity.

I don't know whether it is important for the resolution of this patch,
but what did you mean by the following?:

> The type of new_pmevcntr means you don't have to clear any
> high bits either.

> > +            /* Detect if this write causes an overflow since we can't predict
> > +             * PMSWINC overflows like we can for other events
> > +             */
> > +            uint64_t new_pmswinc = env->cp15.c14_pmevcntr[i] + 1;
> > +
> > +            if (!(new_pmswinc & PMEVCNTR_OVERFLOW_MASK) &&
> > +                    (env->cp15.c14_pmevcntr[i] & PMEVCNTR_OVERFLOW_MASK)) {
> > +                env->cp15.c9_pmovsr |= (1 << i);
> > +                new_pmswinc &= ~PMEVCNTR_OVERFLOW_MASK;
> 
> Likewise.

Thanks,

Aaron

  reply	other threads:[~2019-01-18 21:41 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-11 15:20 [Qemu-devel] [PATCH v10 00/14] More fully implement ARM PMUv3 Aaron Lindsay
2018-12-11 15:20 ` [Qemu-devel] [PATCH v10 01/14] migration: Add post_save function to VMStateDescription Aaron Lindsay
2018-12-11 15:20 ` [Qemu-devel] [PATCH v10 02/14] target/arm: Reorganize PMCCNTR accesses Aaron Lindsay
2018-12-11 15:20 ` [Qemu-devel] [PATCH v10 03/14] target/arm: Swap PMU values before/after migrations Aaron Lindsay
2018-12-11 15:20 ` [Qemu-devel] [PATCH v10 04/14] target/arm: Filter cycle counter based on PMCCFILTR_EL0 Aaron Lindsay
2018-12-11 15:20 ` [Qemu-devel] [PATCH v10 05/14] target/arm: Allow AArch32 access for PMCCFILTR Aaron Lindsay
2018-12-11 15:20 ` [Qemu-devel] [PATCH v10 06/14] target/arm: Implement PMOVSSET Aaron Lindsay
2018-12-11 15:20 ` [Qemu-devel] [PATCH v10 07/14] target/arm: Define FIELDs for ID_DFR0 Aaron Lindsay
2018-12-11 15:20 ` [Qemu-devel] [PATCH v10 08/14] target/arm: Make PMCEID[01]_EL0 64 bit registers, add PMCEID[23] Aaron Lindsay
2018-12-11 15:20 ` [Qemu-devel] [PATCH v10 09/14] target/arm: Add array for supported PMU events, generate PMCEID[01]_EL0 Aaron Lindsay
2018-12-11 15:20 ` [Qemu-devel] [PATCH v10 10/14] target/arm: Finish implementation of PM[X]EVCNTR and PM[X]EVTYPER Aaron Lindsay
2019-02-04 19:22   ` [Qemu-devel] [Qemu-arm] " Laurent Desnogues
2019-02-05 13:41     ` Aaron Lindsay OS
2019-02-05 13:54       ` Laurent Desnogues
2018-12-11 15:20 ` [Qemu-devel] [PATCH v10 11/14] target/arm: PMU: Add instruction and cycle events Aaron Lindsay
2018-12-11 15:20 ` [Qemu-devel] [PATCH v10 12/14] target/arm: PMU: Set PMCR.N to 4 Aaron Lindsay
2018-12-11 15:20 ` [Qemu-devel] [PATCH v10 13/14] target/arm: Implement PMSWINC Aaron Lindsay
2018-12-11 15:20 ` [Qemu-devel] [PATCH v10 14/14] target/arm: Send interrupts on PMU counter overflow Aaron Lindsay
2019-01-17 20:26   ` Richard Henderson
2019-01-18 21:40     ` Aaron Lindsay [this message]
2019-01-18 21:58       ` Richard Henderson
2019-01-11 16:22 ` [Qemu-devel] [PATCH v10 00/14] More fully implement ARM PMUv3 Aaron Lindsay
2019-01-18 14:13 ` Peter Maydell
2019-01-23 20:04   ` Aaron Lindsay OS

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=20190118214052.GD5213@quinoa.localdomain \
    --to=aaron@os.amperecomputing.com \
    --cc=alindsay@codeaurora.org \
    --cc=alistair.francis@xilinx.com \
    --cc=crosthwaite.peter@gmail.com \
    --cc=digantd@codeaurora.org \
    --cc=mspradli@codeaurora.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=wei@redhat.com \
    /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).