From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37206) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN6CO-00060f-Lw for qemu-devel@nongnu.org; Thu, 19 May 2011 12:35:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QN6CN-0007Ej-Jg for qemu-devel@nongnu.org; Thu, 19 May 2011 12:35:44 -0400 Received: from david.siemens.de ([192.35.17.14]:32760) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN6CN-0007ET-9S for qemu-devel@nongnu.org; Thu, 19 May 2011 12:35:43 -0400 Message-ID: <4DD546DC.1000703@siemens.com> Date: Thu, 19 May 2011 18:35:40 +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> <4DD505C4.6010604@redhat.com> <4DD50B17.7000205@siemens.com> <4DD511FB.3080901@redhat.com> <4DD51413.1050202@siemens.com> <4DD51468.7050509@redhat.com> <4DD51531.7000701@siemens.com> <4DD515F9.1020902@redhat.com> <4DD51A82.7060205@siemens.com> <4DD51B64.8000306@redhat.com> <4DD51FDA.3010107@codemonkey.ws> <4DD520ED.8010606@redhat.com> <4DD5260A.1080309@codemonkey.ws> <4DD5272F.5000003@siemens.com> <4DD52848.6030102@codemonkey.ws> <4DD52910.4080106@siemens.com> <4DD52B0E.2080604@codemonkey.ws> <4DD52BF2.2080506@redhat.com> <4DD54611.6090505@codemonkey.ws> In-Reply-To: <4DD54611.6090505@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 18:32, Anthony Liguori wrote: > On 05/19/2011 09:40 AM, Avi Kivity wrote: >> On 05/19/2011 05:37 PM, Anthony Liguori wrote: >>> >>> So.... do you do: >>> >>> isa_register_region(ISABus *bus, MemoryRegion *mr, int priority) >>> { >>> chipset_register_region(bus->chipset, mr, priority + 1); >>> } >>> >>> I don't really understand how you can fold everything into one table >>> and not allow devices to override their parents using priorities. >> >> Think of how a window manager folds windows with priorities onto a flat >> framebuffer. >> >> You do a depth-first walk of the tree. For each child list, you iterate >> it from the lowest to highest priority, allowing later subregions >> override earlier subregions. >> > > Okay, but this doesn't explain how you'll let RAM override the VGA > mapping since RAM is not represented in the same child list as VGA (RAM > is a child of the PMC whereas VGA is a child of ISA/PCI, both of which > are at least one level removed from the PMC). You can always create a new memory region with higher priority, pointing to the RAM window you want to have above VGA. That's what we do today as well, just with different effects on the internal representation. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux