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
