From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57326) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0VNb-0000FS-0F for qemu-devel@nongnu.org; Mon, 05 Sep 2011 05:22:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R0VNZ-0003JG-Kz for qemu-devel@nongnu.org; Mon, 05 Sep 2011 05:22:10 -0400 Received: from mail-ew0-f45.google.com ([209.85.215.45]:45009) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0VNY-0003J3-Vd for qemu-devel@nongnu.org; Mon, 05 Sep 2011 05:22:09 -0400 Received: by ewy24 with SMTP id 24so2306453ewy.4 for ; Mon, 05 Sep 2011 02:22:07 -0700 (PDT) Date: Mon, 5 Sep 2011 11:22:05 +0200 From: "Edgar E. Iglesias" Message-ID: <20110905092205.GC26890@edde.se.axis.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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E648D75.3000303@redhat.com> 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 On Mon, Sep 05, 2011 at 11:51:01AM +0300, Avi Kivity wrote: > On 09/05/2011 11:38 AM, Edgar E. Iglesias wrote: > > > > > > We shouldn't really use the term IRQ as it's confusing. I like the term > > > "pin" better because that describes what we're really talking about. > > > > > > qemu_irq is designed oddly today because is represents something that is > > > intrinsically state (whether a pin is high or low) with an edge > > > notification with the assumption that the state is held somewhere else > > > (which is usually true). > > > > 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 represent, > > 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. But I do think there > should be a way for the sink to query the line level. Whether it is > implemented 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 triggers. I think it is important. Because you need to at least be able to mark the places were there is state. The cache at the sink sounds more right to me. An IRQ line, can at the same time have multiple states through its path between source device and the final sink. Every device that needs to model state should implement/mark it or maybe connect the the generic caching sink version and devices that manipulate the level but dont have state, shouldn't. > (real hardware can query a line at any time, yes?) IMO, the "query" is just an upside-down way of thinking of it. What happens is, you change some state, and the state drives changes through a logic path towards new state that picks up the updated value etc etc. Quering is like going (for bus accesses): OK, here's my VGA framebuffer address, lets do a get back through the bus and see what the CPU wants to write to this location? According to the query view, you would add state to the memory regions so that an MMIO device only gets a xxx_access call, and does a query back to the core to figure out what's going on. Possible? I'm sure it is. Correct? who knows. But IMO, a very upside-down way of thinking of it. Cheers