From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53682) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QNR3J-0005eG-TS for qemu-devel@nongnu.org; Fri, 20 May 2011 10:51:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QNR3I-0000xL-TH for qemu-devel@nongnu.org; Fri, 20 May 2011 10:51:45 -0400 Received: from mail-gw0-f45.google.com ([74.125.83.45]:53790) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QNR3I-0000xE-Pa for qemu-devel@nongnu.org; Fri, 20 May 2011 10:51:44 -0400 Received: by gwb19 with SMTP id 19so1536623gwb.4 for ; Fri, 20 May 2011 07:51:44 -0700 (PDT) Message-ID: <4DD67FFD.50604@codemonkey.ws> Date: Fri, 20 May 2011 09:51:41 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <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> <20110519161731.GA27310@redhat.com> <4DD5446A.6030003@siemens.com> <20110519162805.GC27310@redhat.com> <4DD545B2.70705@siemens.com> <4DD54729.8050707@codemonkey.ws> <4DD62CA5.9050005@redhat.com> In-Reply-To: <4DD62CA5.9050005@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/20/2011 03:56 AM, Avi Kivity wrote: > On 05/19/2011 07:36 PM, Anthony Liguori wrote: >>> There are no global priorities. Priorities are only used inside each >>> level of the memory region hierarchy to generate a resulting, flattened >>> view for the next higher level. At that level, everything imported from >>> below has the default prio again, ie. the lowest one. >> >> >> Then SMM is impossible. >> > > It doesn't follow. > >> Why do we need priorities at all? There should be no overlap at each >> level in the hierarchy. > > Of course there is overlap. PCI BARs overlap each other, the VGA windows > and ROM overlap RAM. Here's what I'm still struggling with: If children normally overlap their parents, but child priorities are always less than their parents, then what's the benefit of having anything more than two priorities settings. As far as I can understand it, a priority of 0 means "let children windows overlap" whereas a priority of 1 means "don't let children windows overlap". Is there a use-case for a priority above 1 and if so, what does it mean? >> If you have overlapping BARs, the PCI bus will always send the request >> to a single device based on something that's implementation specific. >> This works because each PCI device advertises the BAR locations and >> sizes in it's config space. > > BARs in general don't need priority, except we need to decide if BARs > overlap RAM of vice-versa. > >> >> To dispatch a request, the PCI bus will walk the config space to find >> a match. If you remove something that was previously causing an >> overlap, it'll the other device will now get the I/O requests. > > That's what *exactl* what priority means. Which device is in front, and > which is in the back. Why not use registration order to resolve this type of conflict? What are the use cases to use priorities where registration order wouldn't be adequate? >> There is no need to have centralized logic to decide this. >> > > I think you're completely missing the point of my proposal. I'm struggling to find the mental model for priorities. I may just be dense here but the analogy of transparent window ordering isn't helping me. Regards, Anthony Liguori