From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43339) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0VUA-000255-7f for qemu-devel@nongnu.org; Mon, 05 Sep 2011 05:29:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R0VU9-0004bt-Da for qemu-devel@nongnu.org; Mon, 05 Sep 2011 05:28:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:62694) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0VU9-0004bp-2V for qemu-devel@nongnu.org; Mon, 05 Sep 2011 05:28:57 -0400 Message-ID: <4E649652.1000404@redhat.com> Date: Mon, 05 Sep 2011 12:28:50 +0300 From: Avi Kivity MIME-Version: 1.0 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> <20110905092205.GC26890@edde.se.axis.com> In-Reply-To: <20110905092205.GC26890@edde.se.axis.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: "Edgar E. Iglesias" Cc: Lucas Meneghel Rodrigues , Marcelo Tosatti , qemu-devel , Blue Swirl , Jan Kiszka , Gerd Hoffmann On 09/05/2011 12:22 PM, Edgar E. Iglesias wrote: > > (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. There's no difference really. Consider reading the 'data' parameter a query. With qemu_irq, there is a difference, because the line level is valid at all times, not just when the edge takes place (for memory, the data lines are only valid during the transaction). > But IMO, a very upside-down way of thinking of it. > Query is needed when a line is masked internally, or when a device is hot-plugged. We can work around masking by caching the level in the device even though the line is masked, and querying the cache when the line is unmasked, but that is artificial, and requires live-migrating the cache (which isn't true state). We can't work around the hotplug case. -- error compiling committee.c: too many arguments to function