From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=43195 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OHMvQ-000176-6d for qemu-devel@nongnu.org; Wed, 26 May 2010 16:10:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OHMvO-0008T2-KC for qemu-devel@nongnu.org; Wed, 26 May 2010 16:10:00 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]:56237) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OHMvO-0008Sq-9o for qemu-devel@nongnu.org; Wed, 26 May 2010 16:09:58 -0400 Message-ID: <4BFD8010.3010001@web.de> Date: Wed, 26 May 2010 22:09:52 +0200 From: Jan Kiszka 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> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig26D76D24259EB1DA2BA08BFB" Sender: jan.kiszka@web.de List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: qemu-devel@nongnu.org, Juan Quintela This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig26D76D24259EB1DA2BA08BFB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Blue Swirl wrote: > 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 wrot= e: >>>> >>>>> From: Jan Kiszka >>>>> >>>>> This allows to communicate potential IRQ coalescing during delivery= from >>>>> 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 IR= Q >>>>> redirections. If the IRQ source receives a QEMU_IRQ_COALESCED, it c= an >>>>> 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, bidirectiona= l >>>> multi-level, which is not correct. >>>> >>> I don't think it's really an issue of correct, but I wouldn't disagre= e >>> to a suggestion that we ought to introduce a new signal type for this= >>> type of bidirectional feedback. Maybe it's qemu_coalesced_irq and ha= s 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 intern= al >>>> 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 generi= c >> interface - nothing really "won". >=20 > OK, let's simplify: just reinject at next possible chance. No need to > monitor or tell anything. There are guests that won't like this (I know of one in-house, but others may even have more examples), specifically if you end up firing multiple IRQs in a row due to a longer backlog. For that reason, the RTC spreads the reinjection according to the current rate. And even if the rate did not matter, the APIC woult still have to now about the fact that an IRQ is really periodic and does not only appear as such for a certain interval. This really does not sound like simplifying things or even make them cleaner. Jan --------------enig26D76D24259EB1DA2BA08BFB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkv9gBQACgkQitSsb3rl5xQ19gCeKul49+hxMWN7m7jOJYqdLQrn 5KoAnA0seqT64RkR0GA14PQK8Nk3qJa+ =VOlB -----END PGP SIGNATURE----- --------------enig26D76D24259EB1DA2BA08BFB--