From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:49446) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RSao8-0006Ex-U8 for qemu-devel@nongnu.org; Mon, 21 Nov 2011 15:49:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RSao4-0007so-VF for qemu-devel@nongnu.org; Mon, 21 Nov 2011 15:49:40 -0500 Received: from mail-yx0-f173.google.com ([209.85.213.173]:53997) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RSao4-0007sk-R0 for qemu-devel@nongnu.org; Mon, 21 Nov 2011 15:49:36 -0500 Received: by yenq2 with SMTP id q2so6210402yen.4 for ; Mon, 21 Nov 2011 12:49:36 -0800 (PST) Message-ID: <4ECAB95C.5010304@codemonkey.ws> Date: Mon, 21 Nov 2011 14:49:32 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1321368671-1134-1-git-send-email-stefano.stabellini@eu.citrix.com> <4EC27D0D.3040204@codemonkey.ws> <4EC671AF.5030805@codemonkey.ws> <4EC9146E.1070608@redhat.com> In-Reply-To: <4EC9146E.1070608@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/4] xen: introduce mc146818rtcxen List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: "xen-devel@lists.xensource.com" , "agraf@suse.de" , Stefano Stabellini , "qemu-devel@nongnu.org" On 11/20/2011 08:53 AM, Avi Kivity wrote: > On 11/18/2011 04:54 PM, Anthony Liguori wrote: >> >> Thinking more about it, I think this entire line of thinking is wrong >> (including mine) :-) >> >> The problem you're trying to solve is that the RTC fires two 1 second >> timers regardless of whether the guest is reading the wall clock time, >> right? And since wall clock time is never read from the QEMU RTC in >> Xen, it's a huge waste? >> >> The Right Solution would be to modify the RTC emulation such that it >> did a qemu_get_clock() during read of the CMOS registers in order to >> ensure the time was up to date (instead of using 1 second timers). >> >> Then the timers wouldn't even exist anymore. > > That would make host time adjustments (suspend/resume) be reflected in > the guest. qemu_get_clock(rtc_clock) It depends on what clock rtc_clock is tied too. If it's tied to vm_clock, it won't be affected. > Not sure if that's good or bad, but it's different. Doing this wouldn't change the behavior. I presume you were confusing qemu_get_clock() with qemu_get_timedate(). But our current default behavior has the characteristic that you're concerned about. It's was a conscious decision. See: commit 6875204c782e7c9aa5c28f96b2583fd31c50468f Author: Jan Kiszka Date: Tue Sep 15 13:36:04 2009 +0200 Enable host-clock-based RTC Regards, Anthony Liguori