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: Jan Kiszka
Subject: Re: [Qemu-devel] [RFC][PATCH 0/3] Let RTC follow backward jumps of host clock immediately
Date: Wed, 12 Jan 2011 14:05:45 +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 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



reply via email to

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