qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Henrique Barboza <danielhb413@gmail.com>
To: "Matheus K. Ferst" <matheus.ferst@eldorado.org.br>,
	qemu-devel@nongnu.org
Cc: richard.henderson@linaro.org, clg@kaod.org, qemu-ppc@nongnu.org,
	groug@kaod.org, david@gibson.dropbear.id.au
Subject: Re: [PATCH v5 02/10] target/ppc: PMU basic cycle count for pseries TCG
Date: Mon, 8 Nov 2021 16:35:25 -0300	[thread overview]
Message-ID: <3b3ba45c-4fbd-bae8-870a-2ce4a830fca4@gmail.com> (raw)
In-Reply-To: <8fab8324-d26d-6d6f-4ba8-47616b064873@eldorado.org.br>



On 11/5/21 09:56, Matheus K. Ferst wrote:
> On 01/11/2021 20:56, Daniel Henrique Barboza wrote:
>> diff --git a/target/ppc/power8-pmu.c b/target/ppc/power8-pmu.c
>> index 3c2f73896f..a0a42b666c 100644
>> --- a/target/ppc/power8-pmu.c
>> +++ b/target/ppc/power8-pmu.c
> 
> <snip>
> 
>> +static bool pmc_is_active(CPUPPCState *env, int sprn)
>> +{
>> +    if (sprn < SPR_POWER_PMC5) {
>> +        return !(env->spr[SPR_POWER_MMCR0] & MMCR0_FC14);
>> +    }
>> +
>> +    return !(env->spr[SPR_POWER_MMCR0] & MMCR0_FC56);
>> +}
>> +
>> +static void pmu_update_cycles(CPUPPCState *env)
>> +{
>> +    uint64_t now = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
>> +    uint64_t time_delta = now - env->pmu_base_time;
>> +    int sprn;
>> +
>> +    for (sprn = SPR_POWER_PMC1; sprn <= SPR_POWER_PMC6; sprn++) {
>> +        if (!pmc_is_active(env, sprn) ||
>> +            getPMUEventType(env, sprn) != PMU_EVENT_CYCLES) {
>> +            continue;
>> +        }
>> +
>> +        /*
>> +         * The pseries and powernv clock runs at 1Ghz, meaning
>> +         * that 1 nanosec equals 1 cycle.
>> +         */
>> +        env->spr[sprn] += time_delta;
>> +    }
>> +
>> +    /*
>> +     * Update base_time for future calculations if we updated
>> +     * the PMCs while the PMU was running.
>> +     */
>> +    if (!(env->spr[SPR_POWER_MMCR0] & MMCR0_FC)) {
>> +        env->pmu_base_time = now;
>> +    }
>> +}
>> +
>> +/*
>> + * A cycle count session consists of the basic operations we
>> + * need to do to support PM_CYC events: redefine a new base_time
>> + * to be used to calculate PMC values and start overflow timers.
>> + */
>> +static void start_cycle_count_session(CPUPPCState *env)
>> +{
>> +    /* Just define pmu_base_time for now */
>> +    env->pmu_base_time = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
>> +}
>> +
>> +void helper_store_mmcr0(CPUPPCState *env, target_ulong value)
>> +{
>> +    target_ulong curr_value = env->spr[SPR_POWER_MMCR0];
>> +    bool curr_FC = curr_value & MMCR0_FC;
>> +    bool new_FC = value & MMCR0_FC;
>> +
>> +    env->spr[SPR_POWER_MMCR0] = value;
> 
> I'm not sure if this is the right place to update MMCR0. If we set both FC and FC14 in one write, the code will call pmu_update_cycles, but PMCs 1-4 will not be updated because pmc_is_active will use the new value to check if the PMCs are frozen.


We can't postpone this MMCR0 update because the PMU might trigger
an overflow when updating the counters, and the event branch will
receive an outdated MMCR0 value. hflags will be outdated when the
thread goes out the branch and it will conflict with the current
hflags value (updated with hreg_compute_hflags).

You're right about the problem with handling FC14/FC56 bits in the
same MMCR0 write though. What I ended up doing was to pass the old
MMCR0 value to pmu_update_cycles(). That way we'll avoid the problem
you described above.

I took a step further and also added a similar handling that were
already being done with the overflow bits (patch 7) with the FC
bits as well. This means that we'll be able to freeze/update the
counters individually while the PMU is running.



Thanks,


Daniel

> 
>> +
>> +    /* MMCR0 writes can change HFLAGS_PMCCCLEAR and HFLAGS_MMCR0FC */
>> +    if (((curr_value & MMCR0_PMCC) != (value & MMCR0_PMCC)) ||
>> +        (curr_FC != new_FC)) {
>> +        hreg_compute_hflags(env);
>> +    }
>> +
>> +    /*
>> +     * In an frozen count (FC) bit change:
>> +     *
>> +     * - if PMCs were running (curr_FC = false) and we're freezing
>> +     * them (new_FC = true), save the PMCs values in the registers.
>> +     *
>> +     * - if PMCs were frozen (curr_FC = true) and we're activating
>> +     * them (new_FC = false), set the new base_time for future cycle
>> +     * calculations.
>> +     */
>> +    if (curr_FC != new_FC) {
>> +        if (!curr_FC) { > +            pmu_update_cycles(env);
>> +        } else {
>> +            start_cycle_count_session(env);
>> +        }
>> +    }
>> +}
> 


  reply	other threads:[~2021-11-08 19:43 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-01 23:56 [PATCH v5 00/10] PMU-EBB support for PPC64 TCG Daniel Henrique Barboza
2021-11-01 23:56 ` [PATCH v5 01/10] target/ppc: introduce PMUEventType and PMU overflow timers Daniel Henrique Barboza
2021-11-01 23:56 ` [PATCH v5 02/10] target/ppc: PMU basic cycle count for pseries TCG Daniel Henrique Barboza
2021-11-05 12:56   ` Matheus K. Ferst
2021-11-08 19:35     ` Daniel Henrique Barboza [this message]
2021-11-01 23:56 ` [PATCH v5 03/10] target/ppc: enable PMU counter overflow with cycle events Daniel Henrique Barboza
2021-11-05 12:56   ` Matheus K. Ferst
2021-11-08 19:45     ` Daniel Henrique Barboza
2021-11-01 23:56 ` [PATCH v5 04/10] target/ppc: enable PMU instruction count Daniel Henrique Barboza
2021-11-01 23:56 ` [PATCH v5 05/10] target/ppc/power8-pmu.c: add PM_RUN_INST_CMPL (0xFA) event Daniel Henrique Barboza
2021-11-01 23:56 ` [PATCH v5 06/10] target/ppc: PMU: handle setting of PMCs while running Daniel Henrique Barboza
2021-11-01 23:56 ` [PATCH v5 07/10] target/ppc/power8-pmu.c: handle overflow bits when PMU is running Daniel Henrique Barboza
2021-11-01 23:56 ` [PATCH v5 08/10] PPC64/TCG: Implement 'rfebb' instruction Daniel Henrique Barboza
2021-11-01 23:56 ` [PATCH v5 09/10] target/ppc: PMU Event-Based exception support Daniel Henrique Barboza
2021-11-08 19:48   ` Matheus K. Ferst
2021-11-08 20:03     ` Daniel Henrique Barboza
2021-11-08 20:34       ` Matheus K. Ferst
2021-11-08 21:03         ` Daniel Henrique Barboza
2021-11-01 23:56 ` [PATCH v5 10/10] target/ppc/excp_helper.c: EBB handling adjustments 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=3b3ba45c-4fbd-bae8-870a-2ce4a830fca4@gmail.com \
    --to=danielhb413@gmail.com \
    --cc=clg@kaod.org \
    --cc=david@gibson.dropbear.id.au \
    --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 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).