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

[Gleb Natapov <gleb@redhat.com>]

On Wed, Jan 12, 2011 at 12:26:25PM +0100, Jan Kiszka wrote:
> Am 23.12.2010 21:45, Zachary Amsden wrote:
> > 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.
> 
> I haven't tried with Windows yet. When does it read the RTC and how can
> I check the outcome?
> 
Windows relies on timely delivery of RTC interrupts to calculate wall
clock. If, dues to the stall described above, interrupts will not be
delivered for some period of time Windows guest may experience time
drift.

--
			Gleb.