Re: RFC: PCI devices passthrough on Arm design proposal

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

+ Rob Herring

On Fri, 17 Jul 2020, Bertrand Marquis wrote:
> >> Regarding the DT entry, this is not coming from us and this is already
> >> defined this way in existing DTBs, we just reuse the existing entry. 
> > 
> > Is it possible to standardize the property and drop the linux prefix?
> 
> Honestly i do not know. This was there in the DT examples we checked so
> we planned to use that. But it might be possible to standardize this.

We could certainly start a discussion about it. It looks like
linux,pci-domain is used beyond purely the Linux kernel. I think that it
is worth getting Rob's advice on this.


Rob, for context we are trying to get Linux and Xen to agree on a
numbering scheme to identify PCI host bridges correctly. We already have
an existing hypercall from the old x86 days that passes a segment number
to Xen as a parameter, see drivers/xen/pci.c:xen_add_device.
(xen_add_device assumes that a Linux domain and a PCI segment are the
same thing which I understand is not the case.) 


There is an existing device tree property called "linux,pci-domain"
which would solve the problem (ignoring the difference in the definition
of domain and segment) but it is clearly marked as a Linux-specific
property. Is there anything more "standard" that we can use?

I can find PCI domains being mentioned a few times in the Device Tree
PCI specification but can't find any associated IDs, and I couldn't find
segments at all.

What's your take on this? In general, what's your suggestion on getting
Xen and Linux (and other OSes which could be used as dom0 one day like
Zephyr) to agree on a simple numbering scheme to identify PCI host
bridges?

Should we just use "linux,pci-domain" as-is because it is already the de
facto standard? It looks like the property appears in both QEMU and
UBoot already.