From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MlMHm-0004X1-9L for qemu-devel@nongnu.org; Wed, 09 Sep 2009 08:28:30 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MlMHh-0004TZ-Io for qemu-devel@nongnu.org; Wed, 09 Sep 2009 08:28:29 -0400 Received: from [199.232.76.173] (port=52363 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MlMHh-0004TG-AM for qemu-devel@nongnu.org; Wed, 09 Sep 2009 08:28:25 -0400 Received: from mx1.redhat.com ([209.132.183.28]:2452) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MlMHg-0000Lv-OP for qemu-devel@nongnu.org; Wed, 09 Sep 2009 08:28:25 -0400 Message-ID: <4AA79F67.9060401@redhat.com> Date: Wed, 09 Sep 2009 15:28:23 +0300 From: Dor Laor MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH] re-set rtc date on reset handler References: <1251822154-5423-1-git-send-email-glommer@redhat.com> <4AA68310.1050209@siemens.com> <4AA68B50.8000805@siemens.com> <4AA68DBB.9080000@siemens.com> In-Reply-To: <4AA68DBB.9080000@siemens.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Reply-To: dlaor@redhat.com List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Blue Swirl , Glauber Costa , aliguori@us.ibm.com, qemu-devel@nongnu.org On 09/08/2009 08:00 PM, Jan Kiszka wrote: > 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". btw: this is not a hack, its virtualization support for rtc. It should be the default when qemu runs along with kvm. > >> >> 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 >