From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KD4Fv-000134-Ml for qemu-devel@nongnu.org; Sun, 29 Jun 2008 17:16:19 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KD4Fr-00012g-86 for qemu-devel@nongnu.org; Sun, 29 Jun 2008 17:16:18 -0400 Received: from [199.232.76.173] (port=42196 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KD4Fq-00012b-WE for qemu-devel@nongnu.org; Sun, 29 Jun 2008 17:16:15 -0400 Received: from mail.codesourcery.com ([65.74.133.4]:54534) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KD4Fq-0002uk-Vf for qemu-devel@nongnu.org; Sun, 29 Jun 2008 17:16:15 -0400 From: Paul Brook Subject: Re: [Qemu-devel] Re: [PATCH 1/3] Change qemu_set_irq() to return status information. Date: Sun, 29 Jun 2008 22:16:09 +0100 References: <20080629140120.5626.1590.stgit@gleb-debian.qumranet.com.qumranet.com> <200806292134.08436.paul@codesourcery.com> <4867F786.7070002@web.de> In-Reply-To: <4867F786.7070002@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806292216.10253.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 Cc: Gleb Natapov , Jan Kiszka On Sunday 29 June 2008, Jan Kiszka wrote: > Paul Brook wrote: > >> The model takes into account that not all interrupt controller are > >> capable to detect missed interrupt (it is possible that there is no > >> interrupt controller at all). In this case irq function should > >> return one and everything will fall back to how it works now. > > > > On a related note the correct way to fix this is "-icount auto". > > You should make sure that your hacks are not enabled when we have a > > realistic virtual timebase. > > Virtual timebases don't help if the guest has to interact with the real > life - ie. clocks you cannot tweak. In the end, you will have to bring > them in sync again, so this approach basically points in the right > direction. That's exactly what -icount auto does. It gradually varies the virtual clock rate to keep it in line with the outside world. You get some clock skew, but that true whatever you do (including the proposed patch). In my experience hacks to prevent "coalescing" of interrupts cause as many problems as they solve. The guest OS can get awfully confused when it compares two different time sources and gets wildly different and conflicting answers. I believe VMware has some fairly sophisticated hacks for this, but it often still doesn't work in practice. Paul