[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [RFC PATCH v1 1/4] arm/pci: PCI setup and PCI host bridge discovery within XEN on ARM.
On Sat, 25 Jul 2020 at 00:46, Stefano Stabellini <sstabellini@xxxxxxxxxx> wrote: > > On Fri, 24 Jul 2020, Julien Grall wrote: > > On Fri, 24 Jul 2020 at 19:32, Stefano Stabellini <sstabellini@xxxxxxxxxx> > > wrote: > > > > If they are not equal, then I fail to see why it would be useful to > > > > have this > > > > value in Xen. > > > > > > I think that's because the domain is actually more convenient to use > > > because a segment can span multiple PCI host bridges. So my > > > understanding is that a segment alone is not sufficient to identify a > > > host bridge. From a software implementation point of view it would be > > > better to use domains. > > > > AFAICT, this would be a matter of one check vs two checks in Xen :). > > But... looking at Linux, they will also use domain == segment for ACPI > > (see [1]). So, I think, they still have to use (domain, bus) to do the > > lookup. > > > > > > In which case, we need to use PHYSDEVOP_pci_mmcfg_reserved so > > > > Dom0 and Xen can synchronize on the segment number. > > > > > > I was hoping we could write down the assumption somewhere that for the > > > cases we care about domain == segment, and error out if it is not the > > > case. > > > > Given that we have only the domain in hand, how would you enforce that? > > > > >From this discussion, it also looks like there is a mismatch between the > > implementation and the understanding on QEMU devel. So I am a bit > > concerned that this is not stable and may change in future Linux version. > > > > IOW, we are know tying Xen to Linux. So could we implement > > PHYSDEVOP_pci_mmcfg_reserved *or* introduce a new property that > > really represent the segment? > > I don't think we are tying Xen to Linux. Rob has already said that > linux,pci-domain is basically a generic device tree property. My concern is not so much the name of the property, but the definition of it. AFAICT, from this thread there can be two interpretation: - domain == segment - domain == (segment, bus) > And if we > look at https://www.devicetree.org/open-firmware/bindings/pci/pci2_1.pdf > "PCI domain" is described and seems to match the Linux definition. > > I do think we need to understand the definitions and the differences. +1 > Reading online [1][2] it looks like a Linux PCI domain matches a "PCI > Segment Group Number" in PCI Express which is probably why Linux is > making the assumption that it is making. > > So maybe it is OK to use domains == segments, but we need to verify this > in the specs and also clarify the terminology we use in a doc for our > own sanity -- I am hoping that Rahul can come up with a good > explanation on the topic :-) I am a bit confused.... You were the one arguing that domain == (segment, bus) in this thread. So may I ask why the interpretation wouldn't be valid anymore? Cheers, > [1] > https://stackoverflow.com/questions/49050847/how-is-pci-segmentdomain-related-to-multiple-host-bridgesor-root-bridges > [2] https://wiki.osdev.org/PCI_Express
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |