From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=53818 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OK4Om-0005kL-1Z for qemu-devel@nongnu.org; Thu, 03 Jun 2010 02:59:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OK4Ok-0001oY-NF for qemu-devel@nongnu.org; Thu, 03 Jun 2010 02:59:27 -0400 Received: from fmmailgate03.web.de ([217.72.192.234]:54559) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OK4Ok-0001nw-Ci for qemu-devel@nongnu.org; Thu, 03 Jun 2010 02:59:26 -0400 Message-ID: <4C0752CB.9030701@web.de> Date: Thu, 03 Jun 2010 08:59:23 +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: <20100530134935.GC24302@redhat.com> <20100530200722.GA6243@redhat.com> <20100531051905.GD24302@redhat.com> <20100601183058.GB6191@redhat.com> <4C074A72.3070507@web.de> <20100603063456.GM24302@redhat.com> In-Reply-To: <20100603063456.GM24302@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig62EFD20A21A5FD0E4061325D" 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) --------------enig62EFD20A21A5FD0E4061325D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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/NACK >>> callbacks and a bigger payload than just 1 bit of level. I think that= >>> could achieve the same coalescing effect as what the bidirectional >>> 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 sound= s >> 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 pointer i= n >> their irqchips or wherever they need it. IRQ routers on platforms that= >> make use of these messages would have to replicate them when forwardin= g >> 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 is > 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 before qemu_set_irq (or rather some new qemu_set_irq_msg) returns. Jan --------------enig62EFD20A21A5FD0E4061325D 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 iEYEARECAAYFAkwHUssACgkQitSsb3rl5xTtIwCg3uVAjsC6YoG6SzvF1qpE62ag uxUAnAuf3WTPI/9mW5snjc4NdJKI4o+/ =qqI0 -----END PGP SIGNATURE----- --------------enig62EFD20A21A5FD0E4061325D--