Am 12.01.2011 13:27, Gleb Natapov wrote: > 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.
Ah, now I remember again. Will check the behavior before/after the patch. Thanks, Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
