Re: [Xen-devel] RFC: [PATCH 1/3] Enhance platform support for PCI

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Mon, 23 Feb 2015, Jan Beulich wrote:
> >>> On 20.02.15 at 18:33, <ian.campbell@xxxxxxxxxx> 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel