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

[Anthony Liguori <aliguori@us.ibm.com>]

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