From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=51533 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OHN0V-0005Uj-VM for qemu-devel@nongnu.org; Wed, 26 May 2010 16:15:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OHN0G-0001Ur-E3 for qemu-devel@nongnu.org; Wed, 26 May 2010 16:15:01 -0400 Received: from mail-pz0-f186.google.com ([209.85.222.186]:49554) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OHN0G-0001US-8w for qemu-devel@nongnu.org; Wed, 26 May 2010 16:15:00 -0400 Received: by pzk16 with SMTP id 16so2937518pzk.22 for ; Wed, 26 May 2010 13:14:58 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20100526080814.GB2618@redhat.com> References: <4BFC3028.6030303@codemonkey.ws> <4BFC44D2.2090608@web.de> <20100526080814.GB2618@redhat.com> From: Blue Swirl Date: Wed, 26 May 2010 20:14:38 +0000 Message-ID: Subject: Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback Content-Type: text/plain; charset=UTF-8 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: Jan Kiszka , qemu-devel@nongnu.org, Juan Quintela On Wed, May 26, 2010 at 8:08 AM, Gleb Natapov wrote: > On Tue, May 25, 2010 at 11:44:50PM +0200, Jan Kiszka wrote: >> > >> >> I think the real solution to coalescing is put the logic inside one >> >> device, in this case APIC because it has the information about irq >> >> delivery. APIC could monitor incoming RTC irqs for frequency >> >> information and whether they get delivered or not. If not, an internal >> >> timer is installed which injects the lost irqs. >> >> That won't fly as the IRQs will already arrive at the APIC with a >> sufficiently high jitter. At the bare minimum, you need to tell the >> interrupt controller about the fact that a particular IRQ should be >> delivered at a specific regular rate. For this, you also need a generic >> interface - nothing really "won". >> > Not only that. Suppose RTC runs with 64Hz frequency and N interrupts > were coalesced during some period. Now the guest reprograms RTC to > 1024Hz. N should be scaled accordingly otherwise reinjection will not > fix the drift. Do you propose to put this logic into APIC to? Interesting case, I don't think this is handled by the current code either. Could this happen if the target machine does not have HPET and the guest runs a tickless kernel? I think the guest would be buggy to reprogram the timer without checking that the interrupt from the previous timer frequency won't interfere, for example by stopping the clock, or doing the reprogramming only at timer interrupt handler. Otherwise the period may be unpredictable for one period, which means that the time base has been lost. But let's consider how this could be handled with the current code (or with the magical interrupts). When doing the scaling, the guest, while reprogramming, is unaware of the old queued interrupts with the previous rate. Why would scaling these be more correct? I'd think the old ones should be just reinjected ASAP without any scaling.