From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48006) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0V4c-0007zD-DL for qemu-devel@nongnu.org; Mon, 05 Sep 2011 05:02:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R0V4b-0007hk-8U for qemu-devel@nongnu.org; Mon, 05 Sep 2011 05:02:34 -0400 Received: from mail-gw0-f45.google.com ([74.125.83.45]:36330) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0V4b-0007he-5y for qemu-devel@nongnu.org; Mon, 05 Sep 2011 05:02:33 -0400 Received: by gwb19 with SMTP id 19so3044463gwb.4 for ; Mon, 05 Sep 2011 02:02:32 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4E648D75.3000303@redhat.com> References: <4E58FC3F.6080809@web.de> <4E5BE7C5.60705@us.ibm.com> <4E5BFF51.9010503@web.de> <4E5C00F0.9070103@redhat.com> <4E5DF096.6070207@redhat.com> <4E6285BB.2010505@codemonkey.ws> <20110905083857.GB26890@edde.se.axis.com> <4E648D75.3000303@redhat.com> Date: Mon, 5 Sep 2011 10:02:31 +0100 Message-ID: From: Peter Maydell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] pc: Clean up PIC-to-APIC IRQ path List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Lucas Meneghel Rodrigues , Marcelo Tosatti , qemu-devel , Blue Swirl , Jan Kiszka , Gerd Hoffmann , "Edgar E. Iglesias" On 5 September 2011 09:51, Avi Kivity wrote: > On 09/05/2011 11:38 AM, Edgar E. Iglesias wrote: >> I don't agree. That's not what qemu_irq represents. >> It represents a wire, a mechanism to drive changes through logic paths >> between state. It is intrinsically stateless. >> >> It may be the case that it is missused in some places, or that it isn't >> always the best thing to use to represent what ever you need to represen= t, >> so that you want to complement with other mechanisms. >> But universally replacing it with a stateful alternative seems wrong to >> me. > I agree that qemu_irq is inherently stateless. =C2=A0But I do think there= should > be a way for the sink to query the line level. =C2=A0Whether it is implem= ented as > a cache of the last qemu_set() level, or with callbacks that query the > underlying state is not important, but we can't just rely on edge trigger= s. > > (real hardware can query a line at any time, yes?) There are often significant constraints (eg "can only query at a clock edge", or "not guaranteed to be valid until some other signal has been high for at least this time"), which often means hardware will latch the input value internally. Obviously QEMU doesn't have to care about things to that level of detail. The reason we don't care is that we're really restricting ourselves to providing a programmer-visible approximatio= n to the device behaviour. So I think the right question to ask about qemu_ir= q semantics is not "does this act like hardware?" but "what is the right interface between two components to let us conveniently implement the behaviour we need?" This probably means that sometimes we want a line with state-querying and sometimes not. Ideally our device/object model ought to (a) let us model either option easily (b) let us easily upgrade a "no state querying" line to a "state querying" line by having the latter's interface be a superset of the former's. [IMHO the most important reason not to call it a qemu_irq is that 'irq' is a description of what the signal is used for, not of its behaviour. 'gpio' is a bit more neutral.] -- PMM