From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46719) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QO3D0-0002a1-4P for qemu-devel@nongnu.org; Sun, 22 May 2011 03:36:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QO3Cz-0002oN-8V for qemu-devel@nongnu.org; Sun, 22 May 2011 03:36:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60763) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QO3Cz-0002oE-1M for qemu-devel@nongnu.org; Sun, 22 May 2011 03:36:17 -0400 Message-ID: <4DD8BCE9.8010001@redhat.com> Date: Sun, 22 May 2011 10:36:09 +0300 From: Avi Kivity 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> <4DD67FFD.50604@codemonkey.ws> In-Reply-To: <4DD67FFD.50604@codemonkey.ws> 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: Anthony Liguori Cc: Jan Kiszka , qemu-devel , Gleb Natapov On 05/20/2011 05:51 PM, Anthony Liguori wrote: >> 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? Children always overlap their parents. Priorities are among children of the same parent. I expect there won't be a use case for priority 2, but that's not because of some inherent property of the design; the hardware designers simply haven't got around to designing such whacky hardware. Note that a container is transparent, so layering several containers on top of each other simply generates a flattening of the tree. You can have an opaque container by having a lowest-priority child that covers the entire address space. >> 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? Registration order is not something you want in a declarative API. There is a non-priority equivalent, and that is to unregister (_del_subregion) all subregions in the contended region, except the one you want. That doesn't work for PCI, since the "contended region" isn't known. You want RAM to hide PCI BARs (or perhaps vice versa), you need to tell the system which one takes precedence. > >>> 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. > If you like, you can think of "priority" as "explicit registration order". The advantage is that is works dynamically, if a region is unregistered and re-registered, that doesn't mess up your registration order. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.