Re: [Qemu-devel] [RFC][PATCH 0/3] Let RTC follow backward jumps of host clock immediately

[Zachary Amsden <zamsden@redhat.com>]

On 12/17/2010 04:58 AM, Jan Kiszka wrote:
> By default, we base the mc146818 RTC on the host clock (CLOCK_REALTIME).
> This works fine if only the frequency of the host clock is tuned (e.g.
> by NTP) or if it is set to a future time. However, if the host is tuned
> backward, e.g. because NTP obtained the correct time after the guest was
> already started or the admin decided to tune the local time, we see an
> unpleasant effect in the guest: The RTC will stall for the period the
> host clock is set back.
>
> This series tries to address the issue more gracefully. By detecting
> those warps and providing a callback mechanism to device models, the
> RTC is enabled to update its timers and register content immediately.
> Tested successfully with a hwclock readout loop in a Linux guest while
> fiddling with the host time.
>
> Note that if this kind of RTC adjustment is not wanted, the user is
> still free to decouple the RTC from the host clock and base it on the
> VM clock - just like before.
>    

Did you test this with a Windows guest?  They rely heavily on RTC, this 
is probably a better behavior for that case.  I'd be curious if Windows 
accepts the RTC register changing underneath it, but based on earlier 
versions of Windows Time Service, would be surprised if it did not.

Zach