From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:35032) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QO3fr-0008Sw-Fa for qemu-devel@nongnu.org; Sun, 22 May 2011 04:06:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QO3fq-0006eE-6K for qemu-devel@nongnu.org; Sun, 22 May 2011 04:06:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:30688) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QO3fp-0006eA-VW for qemu-devel@nongnu.org; Sun, 22 May 2011 04:06:06 -0400 Date: Sun, 22 May 2011 11:06:01 +0300 From: Gleb Natapov Message-ID: <20110522080601.GR27310@redhat.com> References: <4DD5260A.1080309@codemonkey.ws> <4DD5272F.5000003@siemens.com> <4DD52848.6030102@codemonkey.ws> <4DD52910.4080106@siemens.com> <4DD52B0E.2080604@codemonkey.ws> <4DD52BF2.2080506@redhat.com> <20110519162706.GB27310@redhat.com> <4DD62D8E.2010605@redhat.com> <20110520115716.GN27310@redhat.com> <4DD8BD4C.3030109@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DD8BD4C.3030109@redhat.com> 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 On Sun, May 22, 2011 at 10:37:48AM +0300, Avi Kivity wrote: > On 05/20/2011 02:57 PM, Gleb Natapov wrote: > >On Fri, May 20, 2011 at 11:59:58AM +0300, Avi Kivity wrote: > >> On 05/19/2011 07:27 PM, Gleb Natapov wrote: > >> >> 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. > >> >> > >> >I do not think that window manager is a good analogy. Window can > >> >overlap with only its siblings. In our memory tree each final node may > >> >overlap with any other node in the tree. > >> > > >> > >> Transparent windows. > >> > >No, still not that. Think about child windows that resides outside of its > >parent windows on screen. In our memory region terms think about PCI BAR > >is registered to overlap with RAM at address 0x1000 for instance. PCI > >BAR memory region and RAM memory region are on very different branches > >of the global tree. > > Right. But what's the problem with that? > None, unless you want to make PCI BAR visible at address 0x1000 (like what will happen today) the case above. > Which one takes precedence is determined by the priorities of the > RAM subregion vs. the PCI bus subregion. > Yes, and that is why PCI subsystem or platform code can't directly uses memory API to register PCI memory region/RAM memory region respectively, because they wouldn't know what priorities to specify. Only chipset code knows, so the RAM/PCI memory registration should go through chipset code, but even chipset code doesn't know everything. It knows nothing about cpu local memory regions for instance, so all registrations should go through system bus in the end. Is this how API suppose to be used? -- Gleb.