From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MlMjF-0005L7-Fi for qemu-devel@nongnu.org; Wed, 09 Sep 2009 08:56:53 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MlMjA-0005Jx-CM for qemu-devel@nongnu.org; Wed, 09 Sep 2009 08:56:52 -0400 Received: from [199.232.76.173] (port=38513 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MlMj7-0005JW-Ft for qemu-devel@nongnu.org; Wed, 09 Sep 2009 08:56:47 -0400 Received: from thoth.sbs.de ([192.35.17.2]:19924) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MlMj6-0004gB-Rh for qemu-devel@nongnu.org; Wed, 09 Sep 2009 08:56:45 -0400 Message-ID: <4AA7A61C.4050902@siemens.com> Date: Wed, 09 Sep 2009 14:57:00 +0200 From: Jan Kiszka 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> <4AA79F67.9060401@redhat.com> In-Reply-To: <4AA79F67.9060401@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "dlaor@redhat.com" Cc: Blue Swirl , Glauber Costa , "aliguori@us.ibm.com" , "qemu-devel@nongnu.org" Dor Laor wrote: > 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. OK, will call it 'drift-fix'. But enabling it by default in kvm mode should be filed as a separate patch on top of my queue (which will appear soon). Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux