From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=41573 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ONRVn-00025W-1s for qemu-devel@nongnu.org; Sat, 12 Jun 2010 10:17:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ONRVY-0001sX-C0 for qemu-devel@nongnu.org; Sat, 12 Jun 2010 10:16:25 -0400 Received: from mail.codesourcery.com ([38.113.113.100]:48616) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONRVY-0001sS-2J for qemu-devel@nongnu.org; Sat, 12 Jun 2010 10:16:24 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH 09/16] Enable message delivery via IRQs Date: Sat, 12 Jun 2010 15:15:17 +0100 References: <201006121321.04898.paul@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201006121515.17695.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Jan Kiszka , Jan Kiszka , qemu-devel@nongnu.org, Gleb Natapov , Juan Quintela > On Sat, Jun 12, 2010 at 12:21 PM, Paul Brook wrote: > >> This patch allows to optionally attach a message to an IRQ event. The > >> message can contain a payload reference and a callback that the IRQ > >> handler may invoke to report the delivery result. The former can be used > >> to model message signaling interrupts, the latter to cleanly implement > >> IRQ de-coalescing logics. > > > > I don't like this. qemu_irq is a level triggered interface. Redundant > > calls to qemu_set_irq should (in principle) be a no-op. If you want > > message passing then IMO you should be using something else. > > Keeping the optional message and qemu_irq together means that we can > reuse the existing IRQ subsystem. I'd guess something more separated > would need duplicate allocation and delivery support and maybe even > SysBus etc. would need lots of work to support a new class of IRQs. How do you propose message passing is handled when you have nested multi-layer interrupt trees? How long is the message data valid for? Who owns it? How is a receiver meant to know for format of the message being delivered, and who it's intended for? IMO message triggered systems are fundamentally different to level states. qemu_irq represents a level state, and I'd really like for it to stay that way. If we need/want a generic message passing interface, then that's a different problem, and needs to be done in such a way that the devices always agree on the type of message being passed. TBH I preferred the original system whereby the source can query the state of the sink (i.e "are you ignoring this line?"). Note that conceptually this should be *querying* state, not responding to an event. Paul