From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FYnmp-0001QO-IW for qemu-devel@nongnu.org; Wed, 26 Apr 2006 13:26:47 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FYnmm-0001Nc-Pn for qemu-devel@nongnu.org; Wed, 26 Apr 2006 13:26:47 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FYnmm-0001NS-Ip for qemu-devel@nongnu.org; Wed, 26 Apr 2006 13:26:44 -0400 Received: from [81.29.64.88] (helo=mail.shareable.org) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1FYnpV-0000Sc-M5 for qemu-devel@nongnu.org; Wed, 26 Apr 2006 13:29:33 -0400 Date: Wed, 26 Apr 2006 18:26:30 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH] Timer/clock for Linux Message-ID: <20060426172629.GA27652@mail.shareable.org> References: <001501c65dd6$484d7c60$0464a8c0@athlon> <200604252249.58711.paul@codesourcery.com> <20060426130156.GA19293@mail.shareable.org> <200604261521.09177.paul@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200604261521.09177.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: qemu-devel@nongnu.org Paul Brook wrote: > On Wednesday 26 April 2006 14:01, Jamie Lokier wrote: > > Paul Brook wrote: > > > One solution (which is also desirable for other reasons) is to > > > implement some form of guest cycle counting based on the > > > instructions actually executed. Then use that as the high-precision > > > timesource, and use some for of adaptive method to keep host and > > > guest clocks in sync. > > > > That's what I meant, expressed more clearly, except that I meant to > > count guest time based on the real time spent executing guest code, > > rather than counting individual instructions. Thanks! > > How do you propose doing that? It implies you have some way of interrupting > the guest after it has executed a small amount of guest code, where "small" > is less than the resolution+latency of host timer interrupts. Hmm. I hadn't thought that through, but it still works. It doesn't matter if the guest runs, say, for 20ms before its next emulated 1kHz interrupt - so long as it's not dependent on values from the emulated timer chip after 1ms (or any other emulated device which reveals the time). If the guest does read a device which depends on the time, that's an opportunity to interrupt it. Otherwise, from the guest's view, it's just as if the emulated CPU got faster for a while with the interrupts perfectly timed. -- Jamie