From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52961) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN1w6-0001hO-1d for qemu-devel@nongnu.org; Thu, 19 May 2011 08:02:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QN1w4-0007EY-Sn for qemu-devel@nongnu.org; Thu, 19 May 2011 08:02:37 -0400 Received: from goliath.siemens.de ([192.35.17.28]:22902) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN1w4-0007EI-Hw for qemu-devel@nongnu.org; Thu, 19 May 2011 08:02:36 -0400 Message-ID: <4DD506D7.2010101@siemens.com> Date: Thu, 19 May 2011 14:02:31 +0200 From: Jan Kiszka MIME-Version: 1.0 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> <20110519115858.GH28399@redhat.com> In-Reply-To: <20110519115858.GH28399@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:58, Gleb Natapov wrote: > 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. "Controlled" overlapping can indeed simplify the implementation of a dispatcher that wants to flip between putting some region logically over an existing, possibly complex layout and disabling this overlay. For that purpose, the overlay requires a high prio than what is below (using a default priority). Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux