From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36715) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QNLj6-0007QG-GB for qemu-devel@nongnu.org; Fri, 20 May 2011 05:10:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QNLj5-0007GS-Cd for qemu-devel@nongnu.org; Fri, 20 May 2011 05:10:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:3740) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QNLj5-0007GL-33 for qemu-devel@nongnu.org; Fri, 20 May 2011 05:10:31 -0400 Message-ID: <4DD62FFE.8020103@redhat.com> Date: Fri, 20 May 2011 12:10:22 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4DD3C5B9.1080908@redhat.com> <4DD420A5.2020606@web.de> <4DD51CF3.5040306@codemonkey.ws> <4DD51D36.7040504@siemens.com> <20110519173923.GF27310@redhat.com> <4DD55D5B.30008@web.de> <20110519182203.GH27310@redhat.com> In-Reply-To: <20110519182203.GH27310@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/19/2011 09:22 PM, Gleb Natapov wrote: > > > > BARs may overlap with other BARs or with RAM. That's well-known, so PCI > > bridged need to register their regions with the _overlap variant > > unconditionally. In contrast to the current PhysPageDesc mechanism, the > With what priority? It doesn't matter, since the spec doesn't define priorities among PCI BARs. > If it needs to call _overlap unconditionally why not > always call _overlap and drop not _overlap variant? Other uses need non-overlapping registration. > > > > And they do not need to. The APIC regions will be managed by the per-CPU > > region management, reusing the tool box we need for all bridges. It will > > register the APIC page with a priority higher than the default one, thus > > overriding everything that comes from the host bridge. I think that > > reflects pretty well real machine behaviour. > > > What is "higher"? How does it know that priority is high enough? It is well known that 1 > 0, for example. > I > thought, from reading other replies, that priorities are meaningful > only on the same hierarchy level (which kinda make sense), but now you > are saying that you will override PCI address from another part of > the topology? -- per-cpu memory | +--- apic page (prio 1) | +--- global memory (prio 0) -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.