From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43498) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMzJ1-0001IP-RD for qemu-devel@nongnu.org; Thu, 19 May 2011 05:14:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMzJ1-0005Mw-0Z for qemu-devel@nongnu.org; Thu, 19 May 2011 05:14:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:1057) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMzJ0-0005Ms-Lu for qemu-devel@nongnu.org; Thu, 19 May 2011 05:14:06 -0400 Date: Thu, 19 May 2011 12:14:04 +0300 From: Gleb Natapov Message-ID: <20110519091404.GE28399@redhat.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> <4DD4DE8E.8030402@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DD4DE8E.8030402@redhat.com> Subject: Re: [Qemu-devel] [RFC] Memory API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Jan Kiszka , qemu-devel On Thu, May 19, 2011 at 12:10:38PM +0300, Avi Kivity wrote: > On 05/19/2011 12:08 PM, 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? > > The caller is emulating some hub or router and should decide on > priority like real hardware. > > For example, piix gives higher priority to the vga window over RAM. > Hmm, but if a caller of the memory_region_add_subregion() function is a device itself how does it know about chipset priorities. All it wants to tell to the system is that it is ready to handle mmio access in this phys range, but chipset may decide to forward those accesses elsewhere. -- Gleb.