From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=60739 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OH1vu-00019o-0Q for qemu-devel@nongnu.org; Tue, 25 May 2010 17:45:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OH1vo-0001Gg-CC for qemu-devel@nongnu.org; Tue, 25 May 2010 17:45:05 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]:50922) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OH1vn-0001GL-RX for qemu-devel@nongnu.org; Tue, 25 May 2010 17:45:00 -0400 Message-ID: <4BFC44D2.2090608@web.de> Date: Tue, 25 May 2010 23:44:50 +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> In-Reply-To: <4BFC3028.6030303@codemonkey.ws> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3D76212979D9FBB78961C192" Sender: jan.kiszka@web.de List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Blue Swirl , qemu-devel@nongnu.org, Juan Quintela This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3D76212979D9FBB78961C192 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Anthony Liguori wrote: > On 05/25/2010 02:09 PM, Blue Swirl wrote: >> On Mon, May 24, 2010 at 8:13 PM, Jan Kiszka wrote:= >> =20 >>> From: Jan Kiszka >>> >>> This allows to communicate potential IRQ coalescing during delivery f= rom >>> 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. >>> =20 >> 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. >> =20 >=20 > 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. Maybe 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). >=20 >> 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". Jan --------------enig3D76212979D9FBB78961C192 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 iEYEARECAAYFAkv8RNYACgkQitSsb3rl5xT8dwCfSSv01F0x2tCjupwR7klorrDq BzgAn3agS2LXdEgO6Zu3aK9p5RqZuQjX =/mNh -----END PGP SIGNATURE----- --------------enig3D76212979D9FBB78961C192--