From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:54277) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0C14-0000hr-FP for qemu-devel@nongnu.org; Sun, 04 Sep 2011 08:41:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R0C13-0008Ot-Bj for qemu-devel@nongnu.org; Sun, 04 Sep 2011 08:41:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55220) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0C13-0008Oi-2R for qemu-devel@nongnu.org; Sun, 04 Sep 2011 08:41:37 -0400 Message-ID: <4E6371DA.7070304@redhat.com> Date: Sun, 04 Sep 2011 15:40:58 +0300 From: Avi Kivity MIME-Version: 1.0 References: <20110704094358.GA10960@redhat.com> <4E4B7DE1.3050405@cn.fujitsu.com> <4E4C8577.5000608@cn.fujitsu.com> <4E4D2C9F.6040805@redhat.com> <20110826094254.GA6520@redhat.com> <4E59F359.9040506@redhat.com> <20110828114142.GC4875@redhat.com> <4E5A3E36.4010709@redhat.com> <20110828134203.GA6751@redhat.com> <4E5A485D.1020904@redhat.com> <20110904123006.GA23500@redhat.com> In-Reply-To: <20110904123006.GA23500@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] pci: add standard bridge device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Kevin Wolf , Isaku Yamahata , qemu-devel@nongnu.org On 09/04/2011 03:30 PM, Michael S. Tsirkin wrote: > > > > Create a memory region for the bridge's address space. This region > > is not directly added to system_memory or its descendants. > > I do this for each bridge in the hierarchy, right? Each bridge does this independently (so yes). > > fx440 does exactly this, with the following cosmetic changes: > > > > - the windows are different (vga, pci hole, 64-bit pci area, PAMx, SMRAM) > > - instead of mapping them to the parent bridge's > > pci_address_space(), we map them to get_system_memory() > > Hmm, what ties the windows of a child bridge > to be within the windows of a parent? > system_memory | +--- pci0_alias0 (aliases part of pci0) pci0 | +--- pci1_alias0 (a bridge) pci1 | +--- pci2_alias0 (another bridge) pci2 | +--- BAR When rendering the memory hierarchy, the only parts of BAR which are visible are those that fit the clipping regions pci0_alias0 ^ pci1_alias0 ^ pci2_alias0. If there are multiple aliases (like the low and high PCI holes, and PAM, it becomes (pci0_alias0 v pci0_alias1) ^ (pci1_alias0v pci1_alias1) ^ (pci2_alias0 v pci2_alias1). ( "^" == intersection, "v" == union ) -- error compiling committee.c: too many arguments to function