Re: PCI Pass-through in Xen ARM: Draft 4

[Manish Jaggi <mjaggi@caviumnetworks.com>]

On Wednesday 16 September 2015 06:28 PM, Julien Grall wrote:
> On 15/09/15 19:58, Jaggi, Manish wrote:
>>> I can see 2 different solutions:
>>>      1) Let DOM0 pass the first requester ID when registering the bus
>>>         Pros:
>>>          * Less per-platform code in Xen
>>>         Cons:
>>>          * Assume that the requester ID are contiguous. (Is it really a
>>> cons?)
>>>          * Still require quirk for buggy device (i.e requester ID not
>>> correct)
>>>      2) Do it in Xen
>>>         Pros:
>>>          * We are not relying on DOM0 giving the requester ID
>>>              => Not assuming contiguous requester ID
>>>          Cons:
>>>          * Per PCI bridge code to handle the mapping
>>>
>>    We can have (3) that when PHYSDEVOP_pci_add_device is called the sbdf
>> and requesterID both are passed in hypercall.
> The name of the physdev operation is PHYSDEVOP_pci_device_add and not
> PHYSDEVOP_pci_add_device. Please rename it all the usage in the design doc.
>
> Although, we can't modify PHYSDEVOP_pci_device_add because it's part of
> the ABI which is stable.
>
> Based on David's mail, the requester ID of a given device can be found
> using base + devfn where base is the first requesterID of the bus.
>
> IIRC, this is also match the IORT ACPI spec.
>
> So for now, I would extend the physdev you've introduced to add an host
> bridge (PHYSDEV_pci_host_bridge_add) to pass the base requesterID.
The requester-ID is derived from the Node# and ECAM# as per David. I 
guess the ECAM and Node# can be derived from
the cfg_addr.
Each Ecam has a cfg_addr in Thunder, which is mentioned in the pci node 
in device tree.
For thunder I think we don't need to pass requester-ID in the phydevop.
>
> We can think later to introduce a new physdev op to add PCI if we ever
> require unique requesterID (i.e non-contiguous under the same bridge).
>
> Regards,
>
> ---
> Julien Grall