Re: [Xen-devel] PCI Pass-through in Xen ARM: Draft 4

[Julien Grall <julien.grall@xxxxxxxxxx>]

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.

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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel