From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:59712) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QO7jb-00071q-LK for qemu-devel@nongnu.org; Sun, 22 May 2011 08:26:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QO7ja-0007IY-Rz for qemu-devel@nongnu.org; Sun, 22 May 2011 08:26:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43788) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QO7ja-0007HJ-Kt for qemu-devel@nongnu.org; Sun, 22 May 2011 08:26:14 -0400 Message-ID: <4DD900E0.1070907@redhat.com> Date: Sun, 22 May 2011 15:26:08 +0300 From: Avi Kivity MIME-Version: 1.0 References: <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> <4DD8C4A4.9040206@redhat.com> <20110522085916.GT27310@redhat.com> In-Reply-To: <20110522085916.GT27310@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:59 AM, Gleb Natapov wrote: > > There is no problem. If the PCI bus priority is higher than RAM > > priority, then PCI BARs will override RAM. > > > So if memory region has no subregion that covers part of the region > lower prio region is used? Now the same with the pictures: > > -- root > -- PCI 0x00000 - 0x2ffff (prio 0) > -- BAR A 0x1000 - 0x1fff > -- BAR B 0x20000 - 0x20fff > -- RAM 0x00000 - 0x1ffff (prio 1) > > In the tree above at address 0x0 PCI has higher priority, In a previous mail, I asserted that 1 > 0. Under this assumption, PCI has lower priority. > but since > there is no subregion at this range next prio region is used instead > (RAM). Is this correct? Assuming pci prio = 1 and ram prio = 0, yes. > If yes how core knows that container is > transparent like that (RAM container is not)? All containers are transparent. Only RAM and MMIO regions are not. > > >> 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. > OK. What happens if device tries to create subregion outside of PCI > region provided by chipset to PCI bus? What does real hardware do? The region API has an offset and size, and clips anything outside that. However PCI may be more complicated due to 64-bit BARs, we may need an extra API to control clipping. > > > > > 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. > > > Excellent. I would argue that this is exactly the point where an > overlapping can be resolved too :) It is. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.