Re: PCI Pass-through in Xen ARM - Draft 2.

[Manish Jaggi <mjaggi@caviumnetworks.com>]

On Tuesday 07 July 2015 02:16 PM, Manish Jaggi wrote:
>
>
> On Tuesday 07 July 2015 01:48 PM, Julien Grall wrote:
>> Hi Manish,
>>
>> On 07/07/2015 08:10, Manish Jaggi wrote:
>>> On Monday 06 July 2015 05:15 PM, Julien Grall wrote:
>>>> On 06/07/15 12:09, Manish Jaggi wrote:
>>>>>
>>>>> On Monday 06 July 2015 04:13 PM, Julien Grall wrote:
>>>>>> On 05/07/15 06:55, Manish Jaggi wrote:
>>>>>>>>> 4.3 Hypercall for bdf mapping notification to xen
>>>>>>>>> -----------------------------------------------
>>>>>>>>> #define PHYSDEVOP_map_sbdf              43
>>>>>>>>> typedef struct {
>>>>>>>>>        u32 s;
>>>>>>>>>        u8 b;
>>>>>>>>>        u8 df;
>>>>>>>>>        u16 res;
>>>>>>>>> } sbdf_t;
>>>>>>>>> struct physdev_map_sbdf {
>>>>>>>>>        int domain_id;
>>>>>>>>>        sbdf_t    sbdf;
>>>>>>>>>        sbdf_t    gsbdf;
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>> Each domain has a pdev list, which contains the list of all pci
>>>>>>>>> devices.
>>>>>>>>> The
>>>>>>>>> pdev structure already has a sbdf information. The 
>>>>>>>>> arch_pci_dev is
>>>>>>>>> updated to
>>>>>>>>> contain the gsbdf information. (gs- guest segment id)
>>>>>>>>>
>>>>>>>>> Whenever there is trap from guest or an interrupt has to be
>>>>>>>>> injected,
>>>>>>>>> the pdev
>>>>>>>>> list is iterated to find the gsbdf.
>>>>>>>> Can you give more background for this section? i.e:
>>>>>>>>       - Why do you need this?
>>>>>>>>       - How xen will translate the gbdf to a vDeviceID?
>>>>>>> In the context of the hypercall processing.
>>>>>> That wasn't my question. I asked, how Xen will find the mapping 
>>>>>> between
>>>>>> the gdbf and vDeviceID? He doesn't have access to the firmware table
>>>>>> and
>>>>>> therefore not able to find the right one.
>>>>> I believe gsbdf and vDeviceID would be same.
>>>> Xen and the guest need to translate the gsbdf the same way. If this is
>>>> clearly defined by a spec, then you should give a link to it.
>>> They are same, will change sbdf ->DeviceID and gsbdf->vDeviceID.
>>
>> As asked you in the previous mail, can you please prove it? The 
>> function used to get the requester ID (pci_for_each_dma_alias) is 
>> more complex than a simple return sbdf.
> I am not sure what you would like me to prove.
> As of ThunderX Xen code we have assumed sbdf == deviceID. We are not 
> using ACPI as of now. This is our implementation. It cannot be wrong 
> outrightly.
> Can you please suggest what could be the other approach.
>
>>
>> Furthermore, AFAICT, the IORT Table (from ACPI) [1] is used to 
>> specify the relationships between the requester ID and the DeviceID. 
>> So it's not obvious that sbdf == DeviceID.
>>
>>>> If not, you have to explain in this design doc how you plan to have 
>>>> xen
>>>> and the guest using the same vdevID for a given gsbdf.
>>>>
>>>> Regards,
>>>>
>>>
>>
>> [1] 
>> http://infocenter.arm.com/help/topic/com.arm.doc.den0049a/DEN0049A_IO_Remapping_Table.pdf
>>
If ACPI is not used IORT (sbdf - StreamID - deviceID mapping) has to be 
done in device tree.
Can we add this as a TODO. So that first series of patches can be 
accepted with StreamID == DeviceID = sbdf
>>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel