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

["Jaggi, Manish" <Manish.Jaggi@xxxxxxxxxxxxxxxxxx>]

On Thursday 10 September 2015 06:42 AM, Julien Grall wrote:
> Hi Manish,
Hi Julien, sorry for late response..
>
> On 13/08/2015 10:42, Manish Jaggi wrote:
>>   3.2.    Mapping between streamID - deviceID - pci sbdf - requesterID
>> -----------------------------------------------------------------------------
>>   For a simpler case all should be equal to BDF. But there are some 
>> devices
>>   that use the wrong requester ID for DMA transactions. Linux kernel has
>> PCI
>>   quirks for these. How the same be implemented in Xen or a diffrent
>> approach
>>   has to be taken is TODO here.
>>
>>   Till that time, for basic implementation it is assumed that all are 
>> equal
>>   to BDF.
>
> Back to this streamID = DeviceID = requestID = SBDF again...
>
> I've just found a patch for Linux send by one of your colleague about 
> tweaking the requesterID for thunder-X board (See [1]). The most 
> interesting bits are:
>
> static u32 pci_requester_id_ecam(struct pci_dev *dev)
> {
>     return (((pci_domain_nr(dev->bus) >> 2) << 19) |
>         ((pci_domain_nr(dev->bus) % 4) << 16) |
>         (dev->bus->number << 8) | dev->devfn);
> }
>
> static u32 thunder_pci_requester_id(struct pci_dev *dev, u16 alias)
> {
>     int ret;
>
>     ret = thunder_pem_requester_id(dev);
>     if (ret >= 0)
>         return (u32)ret;
>
>     return pci_requester_id_ecam(dev);
> }
>
> Which is then used to override the default function used by ITS to 
> find the deviceID.
>
> AFAICT, this means that you can't safely assume that DeviceID == sBDF 
> even for your platform. Is that right?
Yes.
>
> If so, I'm afraid that you have to handle DeviceID != sBDF (and so on) 
> in your design doc. I.e how do you plan to get the base requester ID.
>
Right. But on our platform the requesterId is uniquely generated from 
bdf. Adding David to confirm that.
> 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.
> Regards,
>
> [1] https://lkml.org/lkml/2015/7/15/703
>
>
>


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