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

[Julien Grall <julien.grall@citrix.com>]

Hi Manish,

On 19/09/2015 21:24, Manish Jaggi wrote:
> 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.

There is no place for "I guess". Any approximation here would lead to 
add more hypercalls because we design the first one on speculation.

> Each Ecam has a cfg_addr in Thunder, which is mentioned in the pci node
> in device tree.

IIUC what you said, you suggest to retrieve the ECAM based on the 
cfg_addr in Xen, right?

If so, this is the wrong way to go we should avoid to have platform 
specific code in Xen as much as possible and get everything either via 
the firmware table (ACPI or DT) or via hypercall.

> For thunder I think we don't need to pass requester-ID in the phydevop.

May I remind you that this design doc is not about Thunder-X but PCI 
passthrough in general. If your platform already requires specific code 
in Xen to get the requester ID, what prevents other to not do the same?

So it looks like to me that adding the base requester-ID in the 
PHYSDEVOP_pci_host_bridge_add is the right way to go.

Regards,

-- 
Julien Grall