From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52236) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0CJy-0003B2-Tl for qemu-devel@nongnu.org; Sun, 04 Sep 2011 09:01:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R0CJx-00045k-M3 for qemu-devel@nongnu.org; Sun, 04 Sep 2011 09:01:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46281) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0CJx-00045c-Ah for qemu-devel@nongnu.org; Sun, 04 Sep 2011 09:01:09 -0400 Date: Sun, 4 Sep 2011 16:01:59 +0300 From: "Michael S. Tsirkin" Message-ID: <20110904130159.GB23500@redhat.com> References: <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> <4E6371DA.7070304@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E6371DA.7070304@redhat.com> Subject: Re: [Qemu-devel] [PATCH] pci: add standard bridge device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Kevin Wolf , Isaku Yamahata , qemu-devel@nongnu.org On Sun, Sep 04, 2011 at 03:40:58PM +0300, Avi Kivity wrote: > 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 ) What about BAR directly behind pci0? That should be unaffected by bridges pci1 and pci2 since the device is not behind that. > -- > error compiling committee.c: too many arguments to function