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

[Edgar E. Iglesias]

On Tue, Aug 23, 2011 at 10:12:05AM +0200, Paolo Bonzini wrote:
> 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).

Interesting idea :)

Cheers