Re: [Qemu-devel] [PATCH 2/2] [RFC] time: refactor QEMU timer to use GHRTimer

[Paolo Bonzini]

On 08/22/2011 10:28 PM, Jan Kiszka wrote:
>   - QEMU_CLOCK_VIRTUAL: Without -icount, same as above, but stops when
>     the guest is stopped. The offset to compensate for stopped
>     times is based on TSC, not sure why. With -icount, things get more
>     complicated, Paolo had some nice explanations for the details.

The TSC is actually out of the picture.  However, it is easy to get 
confused, because the same code handles stopping both the vm_clock and 
the TSC when the guest is paused.  cpu_get_ticks handles the TSC, 
cpu_get_clock handles the clock:

Removing some "uninteresting" details, you have:

/* return the host CPU cycle counter and handle stop/restart */
int64_t cpu_get_ticks(void)
{
    if (!vm_running) {
        return timers_state.cpu_ticks_offset;
    } else {
        int64_t ticks;
        ticks = cpu_get_real_ticks();
        return ticks + timers_state.cpu_ticks_offset;
    }
}

/* return the host CPU monotonic timer and handle stop/restart */
static int64_t cpu_get_clock(void)
{
    int64_t ti;
    if (!vm_running) {
        return timers_state.cpu_clock_offset;
    } else {
        ti = get_clock();
        return ti + timers_state.cpu_clock_offset;
    }
}

which use the same algorithm but with different base clocks (TSC vs. 
CLOCK_MONOTONIC).

With -icount, things get indeed more complicated.  I'll cover only the 
iothread case since all my attempts at understanding the non-iothread 
case failed. :)  The "-icount N" vm_clock has nanosecond resolution just 
like the normal vm_clock, but those are not real nanoseconds.  While the 
CPU is running, each instruction increments the vm_clock by 2^N 
nanoseconds (yes, this is completely bollocks for SMP. :).  When the CPU 
is not running, instead, the vm_clock follows CLOCK_MONOTONIC; the 
rationale is there in qemu-timer.c.

"-icount auto" is the same, except that we try to keep vm_clock roughly 
the same as CLOCK_MONOTONIC by oscillating the clock frequency between 
"-icount N" values that are more representative of the actual execution 
frequency.

On top of this, the VM has to do two things in icount mode. The first is 
to stop execution at the next vm_clock deadline, which means breaking 
translation blocks after executing the appropriate number of 
instructions; this is quite obvious.  The second is to stop execution of 
a TB after any MMIO instruction, in order to recalculate deadlines if 
necessary.  The latter is responsible for most of the icount black magic 
spread all over the tree.  However, it's not that bad: long term, it 
sounds at least plausible to reuse this machinery to run the CPU threads 
outside the iothread lock (and only take it when doing MMIO, just like 
KVM does).

Paolo