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

[Manish Jaggi <mjaggi@caviumnetworks.com>]

On 23/02/15 4:44 pm, Julien Grall wrote:
>
>
> On 23/02/2015 10:59, Manish Jaggi wrote:
>>
>> On 20/02/15 8:09 pm, Ian Campbell wrote:
>>> On Fri, 2015-02-20 at 19:44 +0530, Manish Jaggi wrote:
>>>>> 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 recommend you let this subthread (e.g. the conversation with Jan)
>>> settle upon a preferred course of action before implementing any one
>>> suggestion.
>> Ian we have also to consider for NUMA / multi node where there are two
>> or more its nodes.
>> pci0{
>>
>> msi-parent = <&its0>;
>> }
>>
>> pci1{
>>
>> msi-parent = <&its1>;
>> }
>>
>> This requires parsing pci nodes in xen and create a mapping between pci
>> nodes and its. Xe would need to be aware of PCI nodes in device tree
>> prior to dom0 sending a hypercall. Adding a property to pci node in
>> device tree should be a good approach.
>
> Why do you need it early? Wouldn't be sufficient to retrieve those 
> information when the hypercall pci_device_add is called?
>
The dom0/U device tree should have one 1 its node, xen should map to specific its when trapped.

> What about ACPI case? Does everything necessary live in static table?
>
> Regards,
>