From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=36929 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ONR1O-00047a-Sy for qemu-devel@nongnu.org; Sat, 12 Jun 2010 09:45:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ONR1N-0005dw-Q2 for qemu-devel@nongnu.org; Sat, 12 Jun 2010 09:45:14 -0400 Received: from mail-px0-f173.google.com ([209.85.212.173]:63604) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONR1N-0005dj-Ku for qemu-devel@nongnu.org; Sat, 12 Jun 2010 09:45:13 -0400 Received: by pxi7 with SMTP id 7so585463pxi.4 for ; Sat, 12 Jun 2010 06:45:12 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <201006121321.04898.paul@codesourcery.com> References: <201006121321.04898.paul@codesourcery.com> From: Blue Swirl Date: Sat, 12 Jun 2010 13:44:52 +0000 Message-ID: Subject: Re: [Qemu-devel] [PATCH 09/16] Enable message delivery via IRQs Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook 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 cal= ls to > qemu_set_irq should (in principle) be a no-op. =C2=A0If 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. Also detection of coalesced interrupts depends on reliably detecting sort of redundant calls to qemu_set_irq. There we don't model real level triggered hardware exactly but add some extra magic.