On Mon, 23 Feb 2015, Jan Beulich wrote: > >>> On 20.02.15 at 18:33, <ian.campb...@citrix.com> wrote: > > On Fri, 2015-02-20 at 15:15 +0000, Jan Beulich wrote: > >> > That's the issue we are trying to resolve, with device tree there is no > >> > explicit segment ID, so we have an essentially unindexed set of PCI > >> > buses in both Xen and dom0. > >> > >> How that? What if two bus numbers are equal? There ought to be > >> some kind of topology information. Or if all buses are distinct, then > >> you don't need a segment number. > > > > It's very possible that I simply don't have the PCI terminology straight > > in my head, leading to me talking nonsense. > > > > I'll explain how I'm using it and perhaps you can put me straight... > > > > My understanding was that a PCI segment equates to a PCI host > > controller, i.e. a specific instance of some PCI host IP on an SoC. > > No - there can be multiple roots (i.e. host bridges) on a single > segment. Segments are - afaict - purely a scalability extension > allowing to overcome the 256 bus limit.
Actually this turns out to be wrong. On the PCI MCFG spec it is clearly stated: "The MCFG table format allows for more than one memory mapped base address entry provided each entry (memory mapped configuration space base address allocation structure) corresponds to a unique PCI Segment Group consisting of 256 PCI buses. Multiple entries corresponding to a single PCI Segment Group is not allowed." I think that it is reasonable to expect device tree systems to respect this too. On ACPI systems the MCFG contains all the info we need, however on device tree systems the segment number is missing from the pcie node, so we still need to find a way to agree with Dom0 on which host bridge corresponds to which segnment. In other words I think that we still need PHYSDEVOP_pci_host_bridge_add (http://marc.info/?l=xen-devel&m=142470392016381) or equivalent, but we can drop the bus field from the struct. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel