From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48499) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QO3it-0000g4-Ha for qemu-devel@nongnu.org; Sun, 22 May 2011 04:09:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QO3is-0006sA-KI for qemu-devel@nongnu.org; Sun, 22 May 2011 04:09:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45393) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QO3is-0006s6-Bm for qemu-devel@nongnu.org; Sun, 22 May 2011 04:09:14 -0400 Message-ID: <4DD8C4A4.9040206@redhat.com> Date: Sun, 22 May 2011 11:09:08 +0300 From: Avi Kivity MIME-Version: 1.0 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> <20110522080601.GR27310@redhat.com> In-Reply-To: <20110522080601.GR27310@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: Gleb Natapov Cc: Jan Kiszka , qemu-devel On 05/22/2011 11:06 AM, Gleb Natapov wrote: > 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. There is no problem. If the PCI bus priority is higher than RAM priority, then PCI BARs will override RAM. > > 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, Correct. Chipset code creates RAM and PCI regions, and gives the PCI region to the PCI bus. Devices give BAR subregions to the PCI bus. The PCI bus does the registration. > 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? Yes. Every point where a decision is made on how to route memory accesses is a modelled as a container node. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.