Re: [PATCH qemu.git v2 9/9] hw/timer/imx_epit: fix compare timer handling

[Peter Maydell]

On Mon, 7 Nov 2022 at 16:42, ~axelheider <axelheider@git.sr.ht> wrote:
>
> From: Axel Heider <axel.heider@hensoldt.net>
>
> - fix #1263
> - rework compare time handling
>   - The compare timer has to run even if CR.OCIEN is not set,
>     as SR.OCIF must be updated.
>   - The compare timer fires exactly once when the
>     compare value is less than the current value, but the
>     reload values is less than the compare value.
>   - The compare timer will never fire if the reload value is
>     less than the compare value. Disable it in this case.

If you're correcting behaviour of the timer use here,
you should start by fixing the way the timers are currently
created with PTIMER_POLICY_LEGACY. That setting is basically
"bug-for-bug-compatibility with very old QEMU, for devices
where nobody really knows what the hardware behaviour should
be". Where we do know what the hardware's supposed to do and
we have some way of testing we're not breaking guest code,
the right thing is to set the correct policy flags for
the desired behaviour. These are documented in a comment
near the top of include/hw/ptimer.h.

> Signed-off-by: Axel Heider <axel.heider@hensoldt.net>
> ---
>  hw/timer/imx_epit.c | 188 +++++++++++++++++++++++++++++---------------
>  1 file changed, 123 insertions(+), 65 deletions(-)
>
> diff --git a/hw/timer/imx_epit.c b/hw/timer/imx_epit.c
> index 77bd2b0a2b..cb2880cabc 100644
> --- a/hw/timer/imx_epit.c
> +++ b/hw/timer/imx_epit.c
> @@ -6,6 +6,7 @@
>   * Originally written by Hans Jiang
>   * Updated by Peter Chubb
>   * Updated by Jean-Christophe Dubois <jcd@tribudubois.net>
> + * Updated by Axel Heider
>   *
>   * This code is licensed under GPL version 2 or later.  See
>   * the COPYING file in the top-level directory.
> @@ -110,33 +111,84 @@ static uint64_t imx_epit_read(void *opaque, hwaddr 
> offset, unsigned size)
>      return reg_value;
>  }
>
> -/* Must be called from ptimer_transaction_begin/commit block for 
> s->timer_cmp */
> -static void imx_epit_reload_compare_timer(IMXEPITState *s)
> +/*
> + * Must be called from a ptimer_transaction_begin/commit block for
> + * s->timer_cmp, but outside of a transaction block of s->timer_reload,
> + * so the proper counter value is read.
> + */
> +static void imx_epit_update_compare_timer(IMXEPITState *s)
>  {
> -    if ((s->cr & (CR_EN | CR_OCIEN)) == (CR_EN | CR_OCIEN))  {
> -        /* if the compare feature is on and timers are running */
> -        uint32_t tmp = ptimer_get_count(s->timer_reload);
> -        uint64_t next;
> -        if (tmp > s->cmp) {
> -            /* It'll fire in this round of the timer */
> -            next = tmp - s->cmp;
> -        } else { /* catch it next time around */
> -            next = tmp - s->cmp + ((s->cr & CR_RLD) ? EPIT_TIMER_MAX : 
> s->lr);
> +    uint64_t counter = 0;
> +    bool is_oneshot = false;
> +    /* The compare timer only has to run if the timer peripheral is active
> +     * and there is an input clock, Otherwise it can be switched off.
> +     */

QEMU coding style wants the "/*" on a line of its own in multiline comments.

> +    bool is_active = (s->cr & CR_EN) && imx_epit_get_freq(s);
> +    if (is_active)
> +    {

Brace goes on same line as "if".

> +        /*
> +         * Calculate next timeout for compare timer. Reading the reload
> +         * counter returns proper results only if pending transactions
> +         * on it are committed here. Otherwise stale values are be read.
> +         */
> +        counter = ptimer_get_count(s->timer_reload);
> +        uint64_t limit = ptimer_get_limit(s->timer_cmp);
> +        /* The compare timer is a periodic timer if the limit is at least
> +         * the compare value. Otherwise it may fire at most once in the
> +         * current round.
> +         */
> +        bool is_oneshot = (limit >= s->cmp);
> +        if (counter >= s->cmp) {
> +            /* The compare timer fires in the current round. */
> +            counter -= s->cmp;
> +        } else if (!is_oneshot) {
> +            /*
> +             * The compare timer fires after a reload, as it below the
> +             * compare value already in this round. Note that the counter
> +             * value calculated below can be above the 32-bit limit, which
> +             * is legal here because the compare timer is an internal
> +             * helper ptimer only.
> +             */
> +            counter += limit - s->cmp;
> +        } else {
> +            /*
> +             * The compare timer wont fire in this round, and the limit is

"won't"

> +             * set to a value below the compare value. This practically means
> +             * it will never fire, so it can be switched off.
> +             */
> +            is_active = false;
>          }
> -        ptimer_set_count(s->timer_cmp, next);
>      }
> +
> +    /*
> +     * Set the compare timer and let it run, or stop it. This is agnostic
> +     * of CR.OCIEN bit, as this only matters for interrupt generation. The
> +     * compare timer needs to run in any case, as the SR.OCIF bit must be
> +     * updated even if no interrupt in generated.

"is generated"

> +     * Note that the timer might already be stopped or be running with
> +     * counter values. However, finding out when an update is needed and
> +     * when not is not trivial. It's much easier applying the setting again,
> +     * as this does not harm either and the overhead is negligible.
> +     */

It is modestly harmful because the sequence
   counter = ptimer_get_count(s->timer_reload);
   ...
   ptimer_set_count(s->timer_cmp, counter);

will cause the counter to lose or gain time. This happens because when
you call "get" the ptimer code will look at the current exact
time in nanoseconds and tell you the counter value at that point.
That is probably somewhere in the middle of a timer-clock period
(which runs at whatever frequency you tell the ptimer to use):
for argument's sake, suppose the timer-clock counts every 1000ns.
Suppose at the point of the 'get' the next tick will be in 300ns time.
When you do a "set" that is assumed to be the result of a guest
register write of some kind, and will effectively start a new
timer-clock period. This means the next tick will not be for
a full 1000ns, and we just lost 300ns (or gained 700ns perhaps).

So it's better to avoid this kind of "get-and-then-set" code.

> +    if (is_active) {
> +        ptimer_set_count(s->timer_cmp, counter);
> +        ptimer_run(s->timer_cmp, is_oneshot ? 1 : 0);
> +    } else {
> +        ptimer_stop(s->timer_cmp);
> +    }
> +
>  }

> @@ -274,16 +326,22 @@ static void imx_epit_cmp(void *opaque)
>  {
>      IMXEPITState *s = IMX_EPIT(opaque);
>
> -    /* Set the interrupt status flag to signaled. */
> -    DPRINTF("sr was %d\n", s->sr);
> -    s->sr = 1;
> +    if (s->cr & CR_EN) {
> +        /* Set the interrupt status flag to signaled. */
> +        DPRINTF("sr was %d\n", s->sr);
> +        s->sr = 1;
>
> -    /*
> -     * An actual interrupt is generated only if the peripheral is enabled
> -     * and the interrupt generation is enabled.
> -     */
> -    if ((s->cr & (CR_EN | CR_OCIEN)) == (CR_EN | CR_OCIEN)) {
> -        qemu_irq_raise(s->irq);
> +        /* If CR,OCIEN is set, an actual interrupt is generated */
> +        if (s->cr & CR_OCIEN) {
> +            qemu_irq_raise(s->irq);
> +        }
> +    } else {
> +        /*
> +         * The cmp ptimer is not supposed to be running when the
> +         * peripheral is not enabled. Ignore this. However, it's
> +         * worth investigating why this happened.
> +         */
> +        DPRINTF("compare trigger when timer not enabled\n");

Is this a "can't happen, it would be a bug in this code"? If so,
use assert(). If it's a "guest code can program the timer in
silly ways" situation then either do what the hardware does
or (if it's not clear what that is) do something plausible.
You can use qemu_log_mask(LOG_GUEST_ERROR, ...) to log things
which are "guest has done something silly" if you like.

More generally, please don't introduce new uses of the DPRINTF
macro. For cases which are "this can be useful to the user to
log for debugging either the driver or their guest code" we
have a trace-events facility, where you put a line into
hw/timer/trace-events that specifies the prototype and format
string for the trace event, and then call a corresponding
trace_whatever() function in the code. Some of the other timer
devices do this, if you want to look at how it works.
Older device models like this one still use debug-print macros,
but they're not good practice in new code.

thanks
-- PMM