qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] pci: add standard bridge device


From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH] pci: add standard bridge device
Date: Sun, 04 Sep 2011 16:05:14 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]