From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JdZcs-0001Wz-Lf for qemu-devel@nongnu.org; Sun, 23 Mar 2008 19:29:18 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JdZcr-0001Wf-83 for qemu-devel@nongnu.org; Sun, 23 Mar 2008 19:29:18 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JdZcr-0001WZ-1D for qemu-devel@nongnu.org; Sun, 23 Mar 2008 19:29:17 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JdZcq-0002nT-N7 for qemu-devel@nongnu.org; Sun, 23 Mar 2008 19:29:16 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH] [RFC] Fix time drift of rtc clock + general support Date: Sun, 23 Mar 2008 23:29:09 +0000 References: <1206282453.18800.31.camel@localhost.localdomain> <200803231619.32472.paul@codesourcery.com> <1206312059.30051.9.camel@localhost.localdomain> In-Reply-To: <1206312059.30051.9.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803232329.10474.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, dor.laor@qumranet.com Cc: kvm-devel On Sunday 23 March 2008, Dor Laor wrote: > On Sun, 2008-03-23 at 16:19 +0000, Paul Brook wrote: > > On Sunday 23 March 2008, Dor Laor wrote: > > > --- a/qemu/hw/irq.c > > > +++ b/qemu/hw/irq.c > > > @@ -30,6 +30,8 @@ struct IRQState { > > > int n; > > > }; > > > > > > +uint32_t qemu_irq_acked[NR_IRQ_WORDS]; > > > > This is absolute rubbish. The whole point of the IRQ framework is that it > > doesn't assume a single flat IRQ controller. > > Thanks for the compliments & the review ... > I specifically said that I'll move this variable into per-cpu var. Per-cpu is no better. > Moreover, the translation between irq line to vector is handled by the > 'qemu_get_irq_vector' that calls 'irq_controller_get_vector' should take > care of the translation. > It works for ioapic, I'm not sure if it works for the flat pic case yet. Which shows you've completely missed the point. irq->n is not a globally unique identifier. It's a local per-controller index. qemu has targets with multiple nested interrupt controllers, anything trying to maintain global or per-cpu IRQ lists is fundamentally broken. > Anyway you're welcome to drift without the patch or provide constructive > comments. Well, the patch doesn't even build on non-x86 targets. > > a new timer will be fired to try inject it again soon (==0.1msec) If the guest is missing interrupts, the chances of a 0.1ms interval working are not great. Most likely It's either going trigger immediately, or be delayed significantly and you're going to end up even further behind. If triggering immediately is OK then why not do that all the time? If triggering immediately is not acceptable then you're still going to loose interrupts. Paul