From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=53028 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PVs2S-0004hq-Rk for qemu-devel@nongnu.org; Thu, 23 Dec 2010 15:45:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PVs2M-0000F9-7h for qemu-devel@nongnu.org; Thu, 23 Dec 2010 15:45:26 -0500 Received: from mx1.redhat.com ([209.132.183.28]:12710) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PVs2L-0000Dg-UJ for qemu-devel@nongnu.org; Thu, 23 Dec 2010 15:45:22 -0500 Message-ID: <4D13B4DB.8030801@redhat.com> Date: Thu, 23 Dec 2010 10:45:15 -1000 From: Zachary Amsden MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC][PATCH 0/3] Let RTC follow backward jumps of host clock immediately References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Anthony Liguori , qemu-devel@nongnu.org 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. Zach