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

[Manish Jaggi <mjaggi@caviumnetworks.com>]

On 20/02/15 7:15 pm, Ian Campbell wrote:
> (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).
This seems ok, i will try it out.
>
> 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.
>