[Top][All Lists]
[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: |
Jan Kiszka |
Subject: |
Re: [Qemu-devel] [RFC][PATCH 0/3] Let RTC follow backward jumps of host clock immediately |
Date: |
Wed, 12 Jan 2011 10:04:12 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 |
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