From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ml3Lu-00046t-N8 for qemu-devel@nongnu.org; Tue, 08 Sep 2009 12:15:30 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ml3Lp-00045R-Ig for qemu-devel@nongnu.org; Tue, 08 Sep 2009 12:15:29 -0400 Received: from [199.232.76.173] (port=46539 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ml3Lp-00045O-DS for qemu-devel@nongnu.org; Tue, 08 Sep 2009 12:15:25 -0400 Received: from david.siemens.de ([192.35.17.14]:20151) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Ml3Lo-0003kC-S6 for qemu-devel@nongnu.org; Tue, 08 Sep 2009 12:15:25 -0400 Message-ID: <4AA68310.1050209@siemens.com> Date: Tue, 08 Sep 2009 18:15:12 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1251822154-5423-1-git-send-email-glommer@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH] re-set rtc date on reset handler List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Glauber Costa , aliguori@us.ibm.com, qemu-devel@nongnu.org Blue Swirl wrote: > On Tue, Sep 1, 2009 at 7:22 PM, Glauber Costa wrote: >> guests without a stable timesource such as kvm-clock will grab the wallclock >> from our rtc chip. However, we only sync the date when we first launch qemu. >> If a guest goes through a series of reboot cycles, it will slowly see time >> getting far behind the host. >> >> The proposal of this patch is to set the date to host clock again in the reset >> handler. With this patch, I see a Fedora guest keeping its clock in sync upon >> an ulimited number of reboots. > > A different approach is used in m48t59.c: the guest clock is generated > directly from host clock without any timers and only a fixed offset > (to account for time when guest was stopped) is added, so the clock > will always in sync. Ah, that looks like a useful approach! We currently face the issue of vRTC drifting away from the host time (as the latter is tuned by NTP). Do you or anyone else know if switching the PC RTC over to the scheme used in the m48t59 may have some downsides? If not, I would happily hack up a patch ASAP and suggest it for mainline. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux