From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=46272 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OIhGg-0001qj-94 for qemu-devel@nongnu.org; Sun, 30 May 2010 08:05:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OIhGf-0002tk-0F for qemu-devel@nongnu.org; Sun, 30 May 2010 08:05:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44493) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OIhGe-0002td-Pg for qemu-devel@nongnu.org; Sun, 30 May 2010 08:05:24 -0400 Message-ID: <4C025481.4080002@redhat.com> Date: Sun, 30 May 2010 15:05:21 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback References: <4BFC3028.6030303@codemonkey.ws> <4BFC44D2.2090608@web.de> <4BFD8010.3010001@web.de> <20100527061335.GE5474@redhat.com> <20100528073135.GC17805@redhat.com> <20100528204746.GC3604@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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, Gleb Natapov , Juan Quintela On 05/29/2010 12:15 PM, Blue Swirl wrote: > >>> This would allow counting the executed instructions and limit it. Thus >>> we could emulate a 500MHz CPU on a 2GHz CPU more accurately. >>> >>> >> Why would you want to limit number of instruction executed by guest if >> CPU has nothing else to do anyway? The problem occurs not when we have >> spare cycles so give to a guest, but in opposite case. >> > I think one problem is that the guest has executed too much compared > to what would happen with real HW with a lesser CPU. That explains the > RTC frequency reprogramming case. > The root cause is that while qemu is scheduled out, the real time clock keeps ticking. Since we can't stop real time, we must compensate in other ways. >> So write the code and show us. You haven't show any evidence that RTC is >> the wrong place. RTC knows when interrupt was acknowledge to RTC, it >> know when clock frequency changes, it know when device reset happened. >> APIC knows only that interrupt was coalesced. It doesn't even know that >> it may be masked by a guest in IOAPIC (interrupts delivered while they >> are masked not considered coalesced). >> > Oh, I thought interrupt masking was the reason for coalescing! What > exactly is the reason then? > The above. -- error compiling committee.c: too many arguments to function