>>> On 11.03.15 at 19:26, <stefano.stabell...@eu.citrix.com> wrote: > 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."
For one, what you quote is in no contradiction to what I said. All it specifies is that there shouldn't be multiple MCFG table entries specifying the same segment. Whether on any such segment there is a single host bridge or multiple of them is of no interest here. And then the present x86 Linux code suggests that there might be systems actually violating this (the fact that each entry names not only a segment, but also a bus range also kind of suggests this despite the wording above); see commit 068258bc15 and its neighbors - even if it talks about the address ranges coming from other than ACPI tables, firmware wanting to express them by ACPI tables would have to violate that rule. > I think that it is reasonable to expect device tree systems to respect this > too. Not really - as soon as we leave ACPI land, we're free to arrange things however they suit us best (of course in agreement with other components involved, like Dom0 in this case), and for that case the cited Linux commit is a proper reference that it can (and has been) done differently by system designers. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
