Re: [PATCH v8 06/10] target/ppc: enable PMU instruction count

[David Gibson <david@gibson.dropbear.id.au>]

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

On Wed, Dec 01, 2021 at 10:12:27AM -0300, Daniel Henrique Barboza wrote:
> On 11/30/21 20:52, David Gibson wrote:
> > On Tue, Nov 30, 2021 at 07:24:04PM -0300, Daniel Henrique Barboza wrote:
[snip]
> > > > > +static bool pmu_increment_insns(CPUPPCState *env, uint32_t num_insns)
> > > > > +{
> > > > > +    bool overflow_triggered = false;
> > > > > +    int sprn;
> > > > > +
> > > > > +    /* PMC6 never counts instructions */
> > > > > +    for (sprn = SPR_POWER_PMC1; sprn <= SPR_POWER_PMC5; sprn++) {
> > > > > +        if (pmc_get_event(env, sprn) != PMU_EVENT_INSTRUCTIONS) {
> > > > > +            continue;
> > > > > +        }
> > > > > +
> > > > > +        env->spr[sprn] += num_insns;
> > > > > +
> > > > > +        if (env->spr[sprn] >= PMC_COUNTER_NEGATIVE_VAL &&
> > > > > +            pmc_has_overflow_enabled(env, sprn)) {
> > > > > +
> > > > > +            overflow_triggered = true;
> > > > > +            env->spr[sprn] = PMC_COUNTER_NEGATIVE_VAL;
> > > > 
> > > > Does the hardware PMU actually guarantee that the event will happen
> > > > exactly on the overflow?  Or could you count a few into the negative
> > > > zone before the event is delivered?
> > > 
> > > My understand reading the ISA and from testing with the a real PMU is that yes,
> > > it'll guarantee that the overflow will happen when the counter reaches exactly
> > > 0x80000000.
> > 
> > Ok.  We can't quite achieve that in TCG, which makes forcing the
> > counter to 0x8000000 a reasonable way of faking it.  Might be worth
> > commenting that that's what this is, though.
> 
> Fair enough.

To expand on this a little, I mentioned in connection with cycle
counting that we kind of have a choice as to which illusion to
preserve.  At least assuming that the VM can see a real real-time
clock, we can either preserve the illusion that cycles have the
advertised frequency, or we can preserve the illusion that
instructions take vaguely the right number of cycles to complete.
With TCG, we can't do both.

We have a somewhat similar tradeoff here: do we prioritize matching
the behaviour that the counter will be exactly 0x80000000 at the time
of an overflow interrupt, or do we prioritize matching the behaviour
that the counter is an accurate and exact count of completed
instructions.  The fact that there is a tradeoff and which side we've
chosen is the key point to describe here, I think.

[In this instance, I think we can get closer to getting both sides
right.  I believe there's a way in TCG to clamp the number of
instructions in a translated block - we could set that based on the
distance to overflow of the PMCs.  That sounds very much not worth it
at this stage - we could look at it as a refinement later if we care]

> > > > > +        }
> > > > > +    }
> > > > > +
> > > > > +    return overflow_triggered;
> > > > > +}
> > > > > +
> > > > >    static void pmu_update_cycles(CPUPPCState *env)
> > > > >    {
> > > > >        uint64_t now = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
> > > > > @@ -258,6 +282,20 @@ static void fire_PMC_interrupt(PowerPCCPU *cpu)
> > > > >        return;
> > > > >    }
> > > > > +/* This helper assumes that the PMC is running. */
> > > > > +void helper_insns_inc(CPUPPCState *env, uint32_t num_insns)
> > > > > +{
> > > > > +    bool overflow_triggered;
> > > > > +    PowerPCCPU *cpu;
> > > > > +
> > > > > +    overflow_triggered = pmu_increment_insns(env, num_insns);
> > > > > +
> > > > > +    if (overflow_triggered) {
> > > > > +        cpu = env_archcpu(env);
> > > > > +        fire_PMC_interrupt(cpu);
> > > > > +    }
> > > > > +}
> > > > > +
> > > > >    static void cpu_ppc_pmu_timer_cb(void *opaque)
> > > > >    {
> > > > >        PowerPCCPU *cpu = opaque;
> > > > > diff --git a/target/ppc/translate.c b/target/ppc/translate.c
> > > > > index 9960df6e18..ccc83d0603 100644
> > > > > --- a/target/ppc/translate.c
> > > > > +++ b/target/ppc/translate.c
> > > > > @@ -177,6 +177,7 @@ struct DisasContext {
> > > > >        bool hr;
> > > > >        bool mmcr0_pmcc0;
> > > > >        bool mmcr0_pmcc1;
> > > > > +    bool pmu_frozen;
> > > > >        ppc_spr_t *spr_cb; /* Needed to check rights for mfspr/mtspr */
> > > > >        int singlestep_enabled;
> > > > >        uint32_t flags;
> > > > > @@ -4170,6 +4171,31 @@ static inline void gen_update_cfar(DisasContext *ctx, target_ulong nip)
> > > > >    #endif
> > > > >    }
> > > > > +#if defined(TARGET_PPC64) && !defined(CONFIG_USER_ONLY)
> > > > 
> > > > Should this actually be !CONFIG_USER_ONLY?  IIUC there are
> > > > circumstances where userspace could access the PMU, including
> > > > instruction counting.
> > > 
> > > The user mode will not be able to use the PMU properly because the MMCR1
> > > reg, used to define the events to be sampled, isn't writable by userpace
> > > under any circunstance.
> > 
> > Couldn't they use PMC5 without writing MMCR1?
> 
> 
> Yeah, in theory. Problem state write access to PMCs are granted for MMCR0_PMCC
> 0b10 || 0b11. The PMCC bits of MMCR0 aren't user read/writable (only FC, PMAO and PMAE
> bits can be r/w from userspace, all other bits are filtered out). With the default
> PMCC value of 0b00 the PMCs are readable, but not writable. So in a way userspace can
> start the PMU and see instruction counting in PMC5 but it wouldn't be able to set it
> to a specific value and wouldn't be able to use overflows.
> 
> All that said, the change to allow PMC5 to be incremented in problem state is simple
> enough so I ended up doing it.

Ok, I think that's a good idea.

You're probably right that at the moment there's no way for a pure
userspace program to access the counters like this.  However, that's
only because of a pretty complex chain of restrictions.  There's no
fundamental reason why we couldn't have some configuration mechanism
to execute a userland program with PMU permission.

-- 
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 --]