From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FYVQ7-0004zJ-Mb for qemu-devel@nongnu.org; Tue, 25 Apr 2006 17:50:07 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FYVQ4-0004yu-0b for qemu-devel@nongnu.org; Tue, 25 Apr 2006 17:50:07 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FYVQ3-0004yr-UW for qemu-devel@nongnu.org; Tue, 25 Apr 2006 17:50:03 -0400 Received: from [65.74.133.6] (helo=mail.codesourcery.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1FYVSb-0007Fc-Fr for qemu-devel@nongnu.org; Tue, 25 Apr 2006 17:52:41 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH] Timer/clock for Linux Date: Tue, 25 Apr 2006 22:49:58 +0100 References: <001501c65dd6$484d7c60$0464a8c0@athlon> <444E905B.5050703@bellard.org> <20060425213455.GA3092@mail.shareable.org> In-Reply-To: <20060425213455.GA3092@mail.shareable.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200604252249.58711.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: qemu-devel@nongnu.org > > QEMU reads the clock at each host wakeup, but it cannot compensate if > > the guest OS requires a higher frequency than the host timer frequency. > > Having a 1 ms period is definitively better to be able to run a wide > > range of guest OSes. > > I was thinking that if the host is woken later than it intended > (e.g. after 2ms with setitimer; could be any amount with any syscall > due to other scheduling delays), then it could fake the timer chip > time it presents to the guest for a short while as if there wasn't > really a timing gap, This isn't possible with the current system. Qemu uses host signals to interrupt itself, ie. to stop executing guest code and process pending interrupts. Thus the minimum available length of a "short delay" is bounded buy the signal latency that you're trying to compensate for. 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. Paul