From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=50127 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OK4VF-00088D-J1 for qemu-devel@nongnu.org; Thu, 03 Jun 2010 03:06:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OK4VA-0002iG-3q for qemu-devel@nongnu.org; Thu, 03 Jun 2010 03:06:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:20811) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OK4V9-0002i9-Re for qemu-devel@nongnu.org; Thu, 03 Jun 2010 03:06:04 -0400 Date: Thu, 3 Jun 2010 10:06:00 +0300 From: Gleb Natapov Subject: Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback Message-ID: <20100603070559.GO24302@redhat.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100603070300.GN24302@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Blue Swirl , qemu-devel@nongnu.org, Juan Quintela 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/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 sounds > > >> 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 in > > >> their irqchips or wherever they need it. IRQ routers on platforms that > > >> make use of these messages would have to replicate them when forwarding > > >> 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. > > > Looks fine to me. > Except that delivery_cb should probably get pointer to qemu_irq_msg as a parameter. -- Gleb.