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

[Jan Kiszka <jan.kiszka@siemens.com>]

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?

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux