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

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

Am 12.01.2011 14:05, Jan Kiszka wrote:
> 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.

Looks good: Without my patches, Windows' clock stops to tick once I
reverse the host time by a significant period. With the patches, the
guest clock proceeds apparently unaffectedly. So this series should be
want-to-have for Windows virtualization as well.

Jan

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