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

[Ian Campbell <ian.campbell@citrix.com>]

(Jan, curious if you have any thoughts on this, hopefully I've left
sufficient context for you to get what we are on about, the gist is we
need some way for dom0 and Xen to agree on how a PCI segment ID maps to
an actual PCI root controller, I think on x86 you either Just Know from
PC legacy or ACPI tells you?)

On Fri, 2015-02-20 at 18:31 +0530, Manish Jaggi wrote:
> I have added ABI that segment no maps to the position on pci node in xen 
> device tree. We had partially discussed about this during Linaro 
> connect. What is your teams view on this, should this be ok or we 
> introduce a property in device tree pci node {xen_segment_id = <1>}

The DT node ordering cannot be relied on this way, so we certainly need
something else.

Ideally we should find a solution which doesn't require new properties.

The best solution would be to find some existing property of the PCI
host controller which is well defined and unique to each host
controller. I had been thinking that the base address of the PCI CFG
space might be a good enough handle.

The only question is whether the data type used for segment id in the
hypercall ABI is wide enough for this, and it seems to be u16 :-(. I'm
not sure if we are going to be able to make this pci_segment_t and have
it differ for ARM.

Another option might be a new hypercall (assuming one doesn't already
exist) to register a PCI bus which would take e.g. the PCI CFG base
address and return a new u16 segment id to be used for all subsequent
PCI related calls. This would require the dom0 OS to hook its
pci_bus_add function, which might be doable (more doable than handling
xen_segment_id DT properties I think).

I'm not sure if this ends up being different on ACPI, where perhaps
MMCONFIG or some other table actually gives us a segment ID for each PCI
bus. Ideally whatever solution we end up with would fit into this model.

Ian.