From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=52951 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pd0m5-0002KN-UG for qemu-devel@nongnu.org; Wed, 12 Jan 2011 08:30:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pd0m4-0001lI-Jt for qemu-devel@nongnu.org; Wed, 12 Jan 2011 08:30:05 -0500 Received: from goliath.siemens.de ([192.35.17.28]:17706) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pd0m4-0001ji-AH for qemu-devel@nongnu.org; Wed, 12 Jan 2011 08:30:04 -0500 Message-ID: <4D2D6E8C.8060801@siemens.com> Date: Wed, 12 Jan 2011 10:04:12 +0100 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC][PATCH 0/3] Let RTC follow backward jumps of host clock immediately References: <4D13B4DB.8030801@redhat.com> <4D2D8FE1.200@siemens.com> <20110112122709.GB6014@redhat.com> <4D2DA729.7030705@siemens.com> In-Reply-To: <4D2DA729.7030705@siemens.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: Anthony Liguori , Zachary Amsden , "qemu-devel@nongnu.org" 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