From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53394) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN1qy-0005Ki-0a for qemu-devel@nongnu.org; Thu, 19 May 2011 07:57:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QN1qx-00068o-0A for qemu-devel@nongnu.org; Thu, 19 May 2011 07:57:19 -0400 Received: from goliath.siemens.de ([192.35.17.28]:23970) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN1qw-00068g-Mf for qemu-devel@nongnu.org; Thu, 19 May 2011 07:57:18 -0400 Message-ID: <4DD5059B.3070907@siemens.com> Date: Thu, 19 May 2011 13:57:15 +0200 From: Jan Kiszka MIME-Version: 1.0 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> <20110519115405.GG28399@redhat.com> In-Reply-To: <20110519115405.GG28399@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 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: Avi Kivity , qemu-devel 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). Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux