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
