From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:32775) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN3WT-0008B3-2Q for qemu-devel@nongnu.org; Thu, 19 May 2011 09:44:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QN3WS-0000Ur-5P for qemu-devel@nongnu.org; Thu, 19 May 2011 09:44:17 -0400 Received: from mail-yw0-f45.google.com ([209.85.213.45]:38599) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN3WS-0000Uf-2d for qemu-devel@nongnu.org; Thu, 19 May 2011 09:44:16 -0400 Received: by ywl41 with SMTP id 41so1050479ywl.4 for ; Thu, 19 May 2011 06:44:15 -0700 (PDT) Message-ID: <4DD51EAC.4080505@codemonkey.ws> Date: Thu, 19 May 2011 08:44:12 -0500 From: Anthony Liguori 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> In-Reply-To: <4DD4DE8E.8030402@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: Avi Kivity Cc: Jan Kiszka , qemu-devel , Gleb Natapov 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). Regards, Anthony Liguori