From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ml43n-0003RJ-VK for qemu-devel@nongnu.org; Tue, 08 Sep 2009 13:00:51 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ml43i-0003LI-Sl for qemu-devel@nongnu.org; Tue, 08 Sep 2009 13:00:51 -0400 Received: from [199.232.76.173] (port=35903 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ml43i-0003LA-PB for qemu-devel@nongnu.org; Tue, 08 Sep 2009 13:00:46 -0400 Received: from david.siemens.de ([192.35.17.14]:19853) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Ml43i-00062u-1e for qemu-devel@nongnu.org; Tue, 08 Sep 2009 13:00:46 -0400 Message-ID: <4AA68DBB.9080000@siemens.com> Date: Tue, 08 Sep 2009 19:00:43 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1251822154-5423-1-git-send-email-glommer@redhat.com> <4AA68310.1050209@siemens.com> <4AA68B50.8000805@siemens.com> In-Reply-To: <4AA68B50.8000805@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: > 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 + ,td-hack=on|off of course. Or let's call it "drift-hack". > > 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 > Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux