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

[Anthony Liguori]

On 08/22/2011 03:49 PM, Jan Kiszka wrote:
> On 2011-08-22 22:36, Anthony Liguori wrote:
> > On 08/22/2011 03:28 PM, Jan Kiszka wrote:
> > > On 2011-08-22 21:21, Anthony Liguori wrote:
> > > > This replaces all of the QEMU timer code with GHRTimer, dramatically
> > > > simplifying
> > > > time keeping in QEMU while making it possible to use QEMUTimer code
> > > > outside of
> > > > the main loop.  The later is critical to building unit tests.
> > > >
> > > > This is an RFC because I'm sure this breaks things as it changes
> > > > things.  QEMU
> > > > time keeping is quite a mess today.  Here's what we do today:
> > > >
> > > > 1) We have three clocks:
> > > >     a) the real time clock, based on system time, not monotonic
> > > >     b) the host clock, based on the real time clock, monotonic by
> > > > detecting
> > > >        movements backward in time
> > > >     c) the vm clock, based on real time clock but may start/stop with
> > > > the guest
> > >
> > > Not quite correct. We have:
> > >
> > >    - QEMU_CLOCK_REALTIME: Based on monotonic source *if* the host
> > >      supports it (there were probably once some stone-old Linuxes or
> > >      BSDs), otherwise based on gettimeofday, i.e. non-monotonic. Always
> > >      monotonic on Windows.
> >
> > The only clock on Linux that is truly monotonic is CLOCK_MONOTONIC_RAW
> > which is very new (2.6.28+).  CLOCK_MONOTONIC is not actually monotonic
> > as it's subject to adjustments.
>
> CLOCK_MONOTONIC may be subject to frequency tuning while
> CLOCK_MONOTONIC_RAW is not. That does not and must not (for POSIX
> compliance) make the former non-monotonic.

Yes, you are right.  I got myself confused.

> > > These two assessments are partly just wrong, partly fail to see the real
> > > use case. QEMU_CLOCK_HOST serves the very valid scenarios where a guest
> > > clock shall be kept synchronized on the host time, also following its
> > > jumps accordingly without stalling timers.
> >
> > The only reason we see jumps at all is because we're using
> > CLOCK_MONOTONIC or CLOCK_REALTIME.  If we used CLOCK_MONOTONIC_RAW, we
> > don't see any jumps at all.
>
> CLOCK_MONOTONIC will not jump backward as well, so is perfectly fine and
> better portable. Backward jumps cannot be avoided when using a host
> system clock that is subject to follow a more accurate external source.
> But having such source for RTC emulation e.g. is a useful feature.

I think its of limited utility.  The RTC isn't universally used for time 
keeping.  There's also no guarantee that the guest isn't going to be 
upset by this.

I think a better approach is to simply have a verb in qemu-ga to set/get 
the guest time.  That let's you implement clock adjustment without 
having to worry about NTP.  I'm happy to add that as part of this series.

I don't think messing around with this stuff belongs in the QEMU clock 
layer though.

Regards,

Anthony Liguori

> Jan