From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52850) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QNLVF-0003gy-LE for qemu-devel@nongnu.org; Fri, 20 May 2011 04:56:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QNLVE-0005TT-JW for qemu-devel@nongnu.org; Fri, 20 May 2011 04:56:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:63112) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QNLVE-0005TM-7R for qemu-devel@nongnu.org; Fri, 20 May 2011 04:56:12 -0400 Message-ID: <4DD62CA5.9050005@redhat.com> Date: Fri, 20 May 2011 11:56:05 +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> In-Reply-To: <4DD54729.8050707@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/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. > > 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. > > To model this correctly, you need to let the PCI bus decide how to > dispatch I/O requests (again, you need hierarchical dispatch). And again, this API gives you hierarchical dispatch, with the addition that some of it is done at registration time so we can prepare the RAM slots. > > In the absence of this, the PCI bus needs to look at all of the > devices, figure out the flat mapping, and register it. When a device > is added or removed, it needs to recalculate the flat mapping and > register it. However we do this, we need to look at all devices. > > There is no need to have centralized logic to decide this. > I think you're completely missing the point of my proposal. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.