From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57376) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0CO4-0004Ci-NQ for qemu-devel@nongnu.org; Sun, 04 Sep 2011 09:05:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R0CO3-00059a-Oe for qemu-devel@nongnu.org; Sun, 04 Sep 2011 09:05:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46043) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0CO3-00059U-HZ for qemu-devel@nongnu.org; Sun, 04 Sep 2011 09:05:23 -0400 Message-ID: <4E63778A.6050002@redhat.com> Date: Sun, 04 Sep 2011 16:05:14 +0300 From: Avi Kivity MIME-Version: 1.0 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> <20110904130159.GB23500@redhat.com> In-Reply-To: <20110904130159.GB23500@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 04:01 PM, Michael S. Tsirkin wrote: > 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. > It follows naturally: system_memory | +--- pci0_alias0 (aliases part of pci0) | pci0 <-+ | +--- pci1_alias0 (a bridge) | | +--- BAR0.0 | | pci1 <-+ | +--- pci2_alias0 (another bridge) | | +--- BAR1.0 | | pci2 <-+ | +--- BAR2.0 BAR0.0 is only filtered by pci0_alias*, BAR1.0 is filtered by pci[01]_alias*. Since pci_register_bar() adds the BAR as a subregion of the bridge's pci_address_space(), it works without any global knowledge, with this topology, or if pci1 and pci2 are siblings instead of parent and child. -- error compiling committee.c: too many arguments to function