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

[Jan Kiszka]

On 2011-08-22 23:55, Anthony Liguori wrote:
>>>> 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.

That's why it's configurable. On the other hand, most guests are
well-prepared to deal with the RTC and the host runtime clock source not
being in sync. That's why we had no bug reports after making this mode
default.

> 
> 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.

That's not that easy in legacy guests, even more when they aren't Linux.

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

It's really not messing, the impact is almost minimal.

Let's focus on the real big pieces first and then see what CLOCK_HOST
actually contributes. That also means you should split up you patches a
bit more, already for better bisectability.

Jan

signature.asc
Description: OpenPGP digital signature