From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52697) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMzT8-0002Or-1H for qemu-devel@nongnu.org; Thu, 19 May 2011 05:24:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMzT6-0006wZ-Vs for qemu-devel@nongnu.org; Thu, 19 May 2011 05:24:33 -0400 Received: from mail-bw0-f45.google.com ([209.85.214.45]:41796) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMzT6-0006wQ-P3 for qemu-devel@nongnu.org; Thu, 19 May 2011 05:24:32 -0400 Received: by bwz16 with SMTP id 16so2400769bwz.4 for ; Thu, 19 May 2011 02:24:31 -0700 (PDT) Date: Thu, 19 May 2011 11:24:28 +0200 From: "Edgar E. Iglesias" Message-ID: <20110519092428.GA20688@edde.se.axis.com> References: <4DD3C5B9.1080908@redhat.com> <4DD3D236.90708@siemens.com> <4DD3D95E.2060105@redhat.com> <4DD3E1B3.3020405@siemens.com> <4DD3E47F.9060104@redhat.com> <4DD3E782.8090208@siemens.com> <4DD3E8D6.6090807@redhat.com> <20110519090851.GD28399@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110519090851.GD28399@redhat.com> Subject: Re: [Qemu-devel] [RFC] Memory API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: Jan Kiszka , Avi Kivity , qemu-devel On Thu, May 19, 2011 at 12:08:51PM +0300, Gleb Natapov wrote: > On Wed, May 18, 2011 at 06:42:14PM +0300, Avi Kivity wrote: > > On 05/18/2011 06:36 PM, Jan Kiszka wrote: > > >> > > >> We need to head for the more hardware-like approach. What happens when > > >> you program overlapping BARs? I imagine the result is > > >> implementation-defined, but ends up with one region decoded in > > >> preference to the other. There is simply no way to reject an > > >> overlapping mapping. > > > > > >But there is also now simple way to allow them. At least not without > > >exposing control about their ordering AND allowing to hook up managing > > >code (e.g. of the PCI bridge or the chipset) that controls registrations. > > > > What about memory_region_add_subregion(..., int priority) as I > > suggested in another message? > Haven't saw another message yet, but how caller knows about priority? I dont think it does, overlap behaviour should be decided by nodes in the bus path from master to slave. I think Anthonys call chain approach makes sense, but it doesn't mean that one cant create a "flat" cached representation of it for fast acceses. The bus (interconnects & bridges) must be able to invalidate it when configuration changes though (leading to a new walk through the call chain and creation of an updated cached "flat" state). Some other comments: On the CPU local aspect, I think it is increasingly common in the embedded space to see local busses with CPU local peripherals in addition to the "system" bus with "global" peripherals. Another thing that was discussed was the ability for devices to know who is accessing them, I think this is uncommon but still it does exist. IIRC an example is the MIPS GIC has some internal decoding based on which CPU is accessing it (but there are other examples). Would be nice to be able to handle it but the accesor info should definitely not be passed to devices by default, it'll only lead to hacks when not strictly necessary... Overall I like the initiaive and look forward to see code and testing it. Cheers