From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51445) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN1sc-0006mt-IX for qemu-devel@nongnu.org; Thu, 19 May 2011 07:59:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QN1sa-0006Hz-RY for qemu-devel@nongnu.org; Thu, 19 May 2011 07:59:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58673) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN1sa-0006Hi-Jk for qemu-devel@nongnu.org; Thu, 19 May 2011 07:59:00 -0400 Date: Thu, 19 May 2011 14:58:58 +0300 From: Gleb Natapov Message-ID: <20110519115858.GH28399@redhat.com> References: <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> <20110519115405.GG28399@redhat.com> <4DD5059B.3070907@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DD5059B.3070907@siemens.com> Subject: Re: [Qemu-devel] [RFC] Memory API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Avi Kivity , qemu-devel On Thu, May 19, 2011 at 01:57:15PM +0200, Jan Kiszka wrote: > On 2011-05-19 13:54, Gleb Natapov wrote: > > 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. > > Devices shall register their regions with the bus. Every device is on > some bus, so that's not a problem. And we can then provide registration > handlers at bus level that either implement specific logic or just > forward the request to the next hierarchy level (default handler). > Yes, I agree with that. I just don't see the need for "priority" parameter in this model. -- Gleb.