From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=56584 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OLARn-0005vc-BW for qemu-devel@nongnu.org; Sun, 06 Jun 2010 03:39:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OLARm-0001li-Ay for qemu-devel@nongnu.org; Sun, 06 Jun 2010 03:39:07 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]:54810) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OLARl-0001ld-UR for qemu-devel@nongnu.org; Sun, 06 Jun 2010 03:39:06 -0400 Message-ID: <4C0B5098.8030800@web.de> Date: Sun, 06 Jun 2010 09:39:04 +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: <20100601183058.GB6191@redhat.com> <4C074A72.3070507@web.de> <20100603063456.GM24302@redhat.com> <4C0752CB.9030701@web.de> <20100603070300.GN24302@redhat.com> <20100603070559.GO24302@redhat.com> <4C099471.3060507@web.de> <20100606071536.GA2337@redhat.com> In-Reply-To: <20100606071536.GA2337@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6E5F9E4829D3E56CB5D27A43" 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) --------------enig6E5F9E4829D3E56CB5D27A43 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Gleb Natapov wrote: > On Sat, Jun 05, 2010 at 02:04:01AM +0200, Jan Kiszka wrote: >>> I'd like to also support EOI handling. When the guest clears the >>> interrupt condtion, the EOI callback would be called. This could occu= r >>> much later than the IRQ delivery time. I'm not sure if we need the >>> result code in that case. >>> >>> If any intermediate device (IOAPIC?) needs to be informed about eithe= r >>> delivery or EOI also, it could create a proxy message with its >>> callbacks in place. But we need then a separate opaque field (in >>> addition to payload) to store the original message. >>> >>> struct IRQMsg { >>> DeviceState *src; >>> void (*delivery_cb)(IRQMsg *msg, int result); >>> void (*eoi_cb)(IRQMsg *msg, int result); >>> void *src_opaque; >>> void *payload; >>> }; >> Extending the lifetime of IRQMsg objects beyond the delivery call stac= k >> means qemu_malloc/free for every delivery. I think it takes a _very_ >> appealing reason to justify this. But so far I do not see any use case= >> for eio_cb at all. >> > I dislike use of eoi for reinfecting missing interrupts since > it eliminates use of internal PIC/APIC queue of not yet delivered > interrupts. PIC and APIC has internal queue that can handle two element= s: > one is delivered, but not yet acked interrupt in isr and another is > pending interrupt in irr. Using eoi callback (or ack notifier as it's > called inside kernel) interrupt will be considered coalesced even if ir= r > is cleared, but no ack was received for previously delivered interrupt.= > But ack notifiers actually has another use: device assignment. There is= > a plan to move device assignment from kernel to userspace and for that > ack notifiers will have to be extended to userspace too. If so we can > use them to do irq decoalescing as well. I doubt they should be part > of IRQMsg though. Why not do what kernel does: have globally registered= > notifier based on irqchip/pin. I read this twice but I still don't get your plan. Do you like or dislike using EIO for de-coalescing? And how should these notifiers work?= Jan --------------enig6E5F9E4829D3E56CB5D27A43 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 iEYEARECAAYFAkwLUJgACgkQitSsb3rl5xRNEACfQb9UpTh3tWKgNTL2aHCZ8G+6 EU0An32MNHahO+ZfuOSMH8+gaP/62cXq =1Lfg -----END PGP SIGNATURE----- --------------enig6E5F9E4829D3E56CB5D27A43--