From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=46246 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OIO84-000203-3l for qemu-devel@nongnu.org; Sat, 29 May 2010 11:39:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OINKE-0005DW-5d for qemu-devel@nongnu.org; Sat, 29 May 2010 10:47:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:4333) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OINKD-000338-Rq for qemu-devel@nongnu.org; Sat, 29 May 2010 10:47:46 -0400 Date: Sat, 29 May 2010 17:46:41 +0300 From: Gleb Natapov Subject: Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback Message-ID: <20100529144641.GF3604@redhat.com> References: <4BFD8010.3010001@web.de> <20100527061335.GE5474@redhat.com> <20100528073135.GC17805@redhat.com> <20100528204746.GC3604@redhat.com> <4C00C921.2060809@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Jan Kiszka , qemu-devel@nongnu.org, Juan Quintela On Sat, May 29, 2010 at 09:35:30AM +0000, Blue Swirl wrote: > > I still don't see how the alternative is supposed to simplify our life > > or improve the efficiency of the de-coalescing workaround. It's rather > > problematic like Gleb pointed out: The de-coalescing logic needs to be > > informed about periodicity changes that can only be delivered along > > IRQs. So what to do with the backlog when the timer is stopped? > > What happens with the current design? Gleb only mentioned the > frequency change, I thought that was not so big problem. But I don't > think this case should be allowed happen at all, it can't exist on > real HW. > Hm, why it can't exist on real HW? Do simple exercise. Run WindowsXP inside QEMU, connect with gdb to QEMU process and check what frequency RTC configured with (hint: it will be 64Hz), now run video inside the guest and check frequency again (hint: it will be 1Khz). -- Gleb.