From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 1/4] xen: introduce mc146818rtcxen Date: Sun, 20 Nov 2011 16:53:34 +0200 Message-ID: <4EC9146E.1070608@redhat.com> References: <1321368671-1134-1-git-send-email-stefano.stabellini@eu.citrix.com> <4EC27D0D.3040204@codemonkey.ws> <4EC671AF.5030805@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4EC671AF.5030805@codemonkey.ws> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org To: Anthony Liguori Cc: "agraf@suse.de" , "xen-devel@lists.xensource.com" , "qemu-devel@nongnu.org" , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org 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. Not sure if that's good or bad, but it's different. -- error compiling committee.c: too many arguments to function