From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52824) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN1nt-00031f-Fz for qemu-devel@nongnu.org; Thu, 19 May 2011 07:54:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QN1ns-0005TW-FH for qemu-devel@nongnu.org; Thu, 19 May 2011 07:54:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:24502) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN1ns-0005TM-6V for qemu-devel@nongnu.org; Thu, 19 May 2011 07:54:08 -0400 Date: Thu, 19 May 2011 14:54:05 +0300 From: Gleb Natapov Message-ID: <20110519115405.GG28399@redhat.com> References: <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> <20110519091404.GE28399@redhat.com> <4DD5029D.6000700@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DD5029D.6000700@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 02:44:29PM +0300, Avi Kivity wrote: > On 05/19/2011 12:14 PM, Gleb Natapov wrote: > >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. > > In this case the device would call a chipset function, passing the > memory region as a parameter, and the chipset would call > m_r_add_subregion(). But then chipset can resolve all overlapping by itself and register only regions that are actually accessible by a guest software. Also there are devices that on some architectures are accessed through a chipset and on other they resides directly on a system bus. If they will need to call different memory registration api depending on how they are instantiated the code can become messy. > Alternatively, the chipset can instantiate the > device (if it is an embedded one) and call m_r_add_subregion() > itself. > -- Gleb.