From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57311) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN1ex-0007uC-Ix for qemu-devel@nongnu.org; Thu, 19 May 2011 07:44:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QN1ew-0003mu-C3 for qemu-devel@nongnu.org; Thu, 19 May 2011 07:44:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:22990) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN1ew-0003mo-1A for qemu-devel@nongnu.org; Thu, 19 May 2011 07:44:54 -0400 Message-ID: <4DD5029D.6000700@redhat.com> Date: Thu, 19 May 2011 14:44:29 +0300 From: Avi Kivity MIME-Version: 1.0 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> <20110519091404.GE28399@redhat.com> In-Reply-To: <20110519091404.GE28399@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 , qemu-devel 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(). Alternatively, the chipset can instantiate the device (if it is an embedded one) and call m_r_add_subregion() itself. -- error compiling committee.c: too many arguments to function