From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ml3tx-0000gW-VS for qemu-devel@nongnu.org; Tue, 08 Sep 2009 12:50:42 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ml3tt-0000ck-DO for qemu-devel@nongnu.org; Tue, 08 Sep 2009 12:50:41 -0400 Received: from [199.232.76.173] (port=50688 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ml3tt-0000cN-6h for qemu-devel@nongnu.org; Tue, 08 Sep 2009 12:50:37 -0400 Received: from thoth.sbs.de ([192.35.17.2]:15023) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Ml3ts-0003Hh-9W for qemu-devel@nongnu.org; Tue, 08 Sep 2009 12:50:36 -0400 Message-ID: <4AA68B50.8000805@siemens.com> Date: Tue, 08 Sep 2009 18:50:24 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1251822154-5423-1-git-send-email-glommer@redhat.com> <4AA68310.1050209@siemens.com> In-Reply-To: <4AA68310.1050209@siemens.com> 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 Jan Kiszka wrote: > 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. Clearly, one downside is that a jumping host time will cause the RTC to jump as well. However, there might by setups where this does not happen, so optionally switching the RTC over rt_clock seems like a reasonable feature to me. What about consolidating -localtime, -starttime and -rtc-td-hack at this chance? Something like -rtc base=utc|localtime|date,clock=vm|rt with 'date' specifying the base as in -starttime. 'clock' would then allow to drive the RTC via the host's CLOCK_REALTIME (with all its pros and cons). Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux