qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Zachary Amsden
Subject: Re: [Qemu-devel] [RFC][PATCH 0/3] Let RTC follow backward jumps of host clock immediately
Date: Thu, 23 Dec 2010 10:45:15 -1000
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100621 Fedora/3.0.5-1.fc13 Thunderbird/3.0.5

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]