From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=42681 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OHMhf-0007WU-7q for qemu-devel@nongnu.org; Wed, 26 May 2010 15:55:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OHMhc-0004wW-Oi for qemu-devel@nongnu.org; Wed, 26 May 2010 15:55:45 -0400 Received: from mail-pw0-f45.google.com ([209.85.160.45]:39311) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OHMhc-0004wQ-J8 for qemu-devel@nongnu.org; Wed, 26 May 2010 15:55:44 -0400 Received: by pwj3 with SMTP id 3so109817pwj.4 for ; Wed, 26 May 2010 12:55:43 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4BFC44D2.2090608@web.de> References: <4BFC3028.6030303@codemonkey.ws> <4BFC44D2.2090608@web.de> From: Blue Swirl Date: Wed, 26 May 2010 19:55:20 +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 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: qemu-devel@nongnu.org, Juan Quintela On Tue, May 25, 2010 at 9:44 PM, Jan Kiszka wrote: > Anthony Liguori wrote: >> On 05/25/2010 02:09 PM, Blue Swirl wrote: >>> On Mon, May 24, 2010 at 8:13 PM, Jan Kiszka =C2=A0wr= ote: >>> >>>> From: Jan Kiszka >>>> >>>> This allows to communicate potential IRQ coalescing during delivery fr= om >>>> the sink back to the source. Targets that support IRQ coalescing >>>> workarounds need to register handlers that return the appropriate >>>> QEMU_IRQ_* code, and they have to propergate the code across all IRQ >>>> redirections. If the IRQ source receives a QEMU_IRQ_COALESCED, it can >>>> apply its workaround. If multiple sinks exist, the source may only >>>> consider an IRQ coalesced if all other sinks either report >>>> QEMU_IRQ_COALESCED as well or QEMU_IRQ_MASKED. >>>> >>> No real devices are interested whether any of their output lines are >>> even connected. This would introduce a new signal type, bidirectional >>> multi-level, which is not correct. >>> >> >> I don't think it's really an issue of correct, but I wouldn't disagree >> to a suggestion that we ought to introduce a new signal type for this >> type of bidirectional feedback. =C2=A0Maybe it's qemu_coalesced_irq and = has a >> similar interface as qemu_irq. > > A separate type would complicate the delivery of the feedback value > across GPIO pins (as Paul requested for the RTC->HPET routing). > >> >>> 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". OK, let's simplify: just reinject at next possible chance. No need to monitor or tell anything.