Re: [RFC PATCH v1 1/4] arm/pci: PCI setup and PCI host bridge discovery within XEN on ARM.

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Fri, 24 Jul 2020, Julien Grall wrote:
> On 24/07/2020 00:38, Stefano Stabellini wrote:
> > > +    bridge->dt_node = dev;
> > > +    bridge->sysdata = cfg;
> > > +    bridge->ops = &ops->pci_ops;
> > > +
> > > +    if( !dt_property_read_u32(dev, "linux,pci-domain", &segment) )
> > > +    {
> > > +        printk(XENLOG_ERR "\"linux,pci-domain\" property in not available
> > > in DT\n");
> > > +        return -ENODEV;
> > > +    }
> > > +
> > > +    bridge->segment = (u16)segment;
> > 
> > My understanding is that a Linux pci-domain doesn't correspond exactly
> > to a PCI segment. See for instance:
> > 
> > https://lists.gnu.org/archive/html/qemu-devel/2018-04/msg03885.html
> > 
> > Do we need to care about the difference? If we mean pci-domain here,
> > should we just call them as such instead of calling them "segments" in
> > Xen (if they are not segments)?
> 
> So we definitely need a segment number in hand because this is what the admin
> will use to assign a PCI device to a guest.

Yeah


> The segment number is just a value defined by the software. So as long as
> Linux and Xen agrees with the number, then we should be ok.

As far as I understand a Linux "domain" (linux,pci-domain in device
tree) is a value defined by the software. The PCI segment has a
definition in the PCI spec and it is returned by _SEG on ACPI systems.

The link above suggests that a Linux domain corresponds to (_SEG,
_BBN) where _SEG is the segment and _BBN is the "Bus Number".

I just would like to be precise with the terminology: if we are talking
about domains in the linux sense of the word, as it looks like we are
doing, then let's call them domain instead of segments which seem to
have a different definition.