From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=48398 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OKgrv-0007Ku-Bd for qemu-devel@nongnu.org; Fri, 04 Jun 2010 20:04:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OKgrt-0000xx-TU for qemu-devel@nongnu.org; Fri, 04 Jun 2010 20:04:07 -0400 Received: from fmmailgate03.web.de ([217.72.192.234]:39035) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OKgrt-0000xn-Fz for qemu-devel@nongnu.org; Fri, 04 Jun 2010 20:04:05 -0400 Message-ID: <4C099471.3060507@web.de> Date: Sat, 05 Jun 2010 02:04:01 +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: <20100530200722.GA6243@redhat.com> <20100531051905.GD24302@redhat.com> <20100601183058.GB6191@redhat.com> <4C074A72.3070507@web.de> <20100603063456.GM24302@redhat.com> <4C0752CB.9030701@web.de> <20100603070300.GN24302@redhat.com> <20100603070559.GO24302@redhat.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig86DBB97CDD0665DFB3D6EA61" 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, Gleb Natapov , Juan Quintela This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig86DBB97CDD0665DFB3D6EA61 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Blue Swirl wrote: > On Thu, Jun 3, 2010 at 7:06 AM, Gleb Natapov wrote: >> On Thu, Jun 03, 2010 at 10:03:00AM +0300, Gleb Natapov wrote: >>> On Thu, Jun 03, 2010 at 08:59:23AM +0200, Jan Kiszka wrote: >>>> Gleb Natapov wrote: >>>>> On Thu, Jun 03, 2010 at 08:23:46AM +0200, Jan Kiszka wrote: >>>>>> Blue Swirl wrote: >>>>>>> But how about if we introduced instead a message based IRQ? Then = the >>>>>>> message could specify the originator device, maybe ACK/coalesce/N= ACK >>>>>>> callbacks and a bigger payload than just 1 bit of level. I think = that >>>>>>> could achieve the same coalescing effect as what the bidirectiona= l >>>>>>> IRQ. The payload could be useful for other purposes, for example >>>>>>> Sparc64 IRQ messages contain three 64 bit words. >>>>>> If there are more users than just IRQ de-coalescing, this indeed s= ounds >>>>>> superior. We could pass objects like this one around: >>>>>> >>>>>> struct qemu_irq_msg { >>>>>> void (*delivery_cb)(int result); >>>>>> void *payload; >>>>>> }; >>>>>> >>>>>> They would be valid within the scope of the IRQ handlers. Whoever >>>>>> terminates or actually delivers the IRQ would invoke the callback.= And >>>>>> platforms like sparc64 could evaluate the additional payload point= er in >>>>>> their irqchips or wherever they need it. IRQ routers on platforms = that >>>>>> make use of these messages would have to replicate them when forwa= rding >>>>>> an event. >>>>>> >>>>>> OK? >>>>>> >>>>> Let me see if I understand you correctly. qemu_set_irq() will get >>>>> additional parameter qemu_irq_msg and if irq was not coalesced >>>>> delivery_cb is called, so there is a guaranty that if delivery_cb i= s >>>>> called it is done before qemu_set_irq() returns. Correct? >>>> If the side that triggers an IRQ passes a message object with a non-= NULL >>>> callback, it is supposed to be called unconditionally, passing the >>>> result of the delivery (delivered, masked, coalesced). And yes, the >>>> callback will be invoked in the context of the irq handler, so befor= e >>>> qemu_set_irq (or rather some new qemu_set_irq_msg) returns. >>>> >>> Looks fine to me. >>> >> Except that delivery_cb should probably get pointer to qemu_irq_msg as= a >> parameter. >=20 > I'd like to also support EOI handling. When the guest clears the > interrupt condtion, the EOI callback would be called. This could occur > much later than the IRQ delivery time. I'm not sure if we need the > result code in that case. >=20 > If any intermediate device (IOAPIC?) needs to be informed about either > 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. >=20 > 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 stack 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. Jan --------------enig86DBB97CDD0665DFB3D6EA61 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 iEYEARECAAYFAkwJlHEACgkQitSsb3rl5xQ88wCgi8MzdiOpa1iYur4JThUH1pOA yLsAni/9wxKffxHkEge+iKWNcQ+1jPnk =ghmO -----END PGP SIGNATURE----- --------------enig86DBB97CDD0665DFB3D6EA61--