From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:33363) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN3ZU-0001pZ-9O for qemu-devel@nongnu.org; Thu, 19 May 2011 09:47:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QN3ZT-00014r-8v for qemu-devel@nongnu.org; Thu, 19 May 2011 09:47:24 -0400 Received: from david.siemens.de ([192.35.17.14]:21737) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN3ZT-00014X-0O for qemu-devel@nongnu.org; Thu, 19 May 2011 09:47:23 -0400 Message-ID: <4DD51F67.2070103@siemens.com> Date: Thu, 19 May 2011 15:47:19 +0200 From: Jan Kiszka 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> <4DD51EAC.4080505@codemonkey.ws> In-Reply-To: <4DD51EAC.4080505@codemonkey.ws> 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: Anthony Liguori Cc: Avi Kivity , Gleb Natapov , qemu-devel On 2011-05-19 15:44, Anthony Liguori wrote: > On 05/19/2011 04:10 AM, 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. > > Well...... > > The i440fx may direct VGA accesses to RAM depending on the SMM > registers. By the time the PIIX gets the I/O request, we're past the > memory controller. > > This is my biggest concern about this whole notion of "priority". These > sort of issues are not dealt with by a simple z-ordering. There is > logic in each component that may be arbitrarily complex. > > We're going to end up having to dynamically change the "priority" based > how registers are programmed. But priorities are relative so it's > unclear to me how the I440FX would prioritize RAM over dispatch to PIIX > (for VGA, for instance). But creating an extra RAM window region with higher priority than the underlying mappings. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux