From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=44968 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OGo26-0006sD-Se for qemu-devel@nongnu.org; Tue, 25 May 2010 02:54:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OGo25-0005Jn-Lf for qemu-devel@nongnu.org; Tue, 25 May 2010 02:54:34 -0400 Received: from fmmailgate01.web.de ([217.72.192.221]:55088) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OGo25-0005JT-3m for qemu-devel@nongnu.org; Tue, 25 May 2010 02:54:33 -0400 Message-ID: <4BFB7422.6030103@web.de> Date: Tue, 25 May 2010 08:54:26 +0200 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback References: <20100525060715.GN22163@redhat.com> <4BFB6EAA.40803@web.de> <20100525064059.GQ22163@redhat.com> In-Reply-To: <20100525064059.GQ22163@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF75E77D381E0B88501D310E4" Sender: jan.kiszka@web.de List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: blue Swirl , qemu-devel@nongnu.org, Juan Quintela This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF75E77D381E0B88501D310E4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Gleb Natapov wrote: > On Tue, May 25, 2010 at 08:31:06AM +0200, Jan Kiszka wrote: >> Gleb Natapov wrote: >>> On Mon, May 24, 2010 at 10:13:40PM +0200, Jan Kiszka wrote: >>>> 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 IRQ= >>>> redirections. If the IRQ source receives a QEMU_IRQ_COALESCED, it ca= n >>>> 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. >>>> >>> Well, almost two years passed since this approach was proposed first >>> time[1] ;). Back then it generated bunch of nonsensical comments abou= t >>> real hardware not working this way, so the hack that we have now was >>> introduce to overcome this resistance. I hope enough time passed for >>> people to gain some sense and the approach will be adopted this time.= >>> Really this should have been done two year ago. >>> >>> [1] http://lists.nongnu.org/archive/html/qemu-devel/2008-06/msg00757.= html >> Yeah, I somehow had a vague feeling that there must have been an earli= er >> attempt. I think my approach could be a slightly easier to accept as i= t >> does not require converting all platforms, but this can happen on dema= nd >> (or not at all). > I proposed that too at some point (to lazy to look for it in archives > and it was in words not patch). But since resistance to that approach > from the beginning was baseless no sane arguments or compromises would > help at that point. >=20 >> Moreover, I think that the third return state, >> QEMU_IRQ_MASKED, is important for correct handling of multiple IRQ sin= ks. > My patch had that too: <0 =3D coalesced, 0 =3D masked, >0=3Ddelivered Oh, indeed! Good to see that we came up with the same logic. >=20 >> However, as I would see it now, we just have two options long term: >> - drop IRQ coalescing workarounds >> - properly support them via qemu_irq >> >> The current hack cannot stay. E.g., it does not scale because it depen= ds >> on a global variable of the APIC. So we would never able to protect th= e >> APICs with individual locks. >> > Agree, and that was well understood at the time the hack was introduced= =2E > But we can't just drop RTC IRQ reinjectoin. It would be crippling of qe= mu. > So we have only _one_ option: > - properly support them via qemu_irq You won't hear me disagreeing. Jan --------------enigF75E77D381E0B88501D310E4 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 iEYEARECAAYFAkv7dCYACgkQitSsb3rl5xQzQgCeLDETD+kS/j9ZGaCqRnkt3MwV 8ksAn22C8kIaQA5p50QUHuTln1q/n3C/ =Apky -----END PGP SIGNATURE----- --------------enigF75E77D381E0B88501D310E4--