Re: [PATCH 09/28] ARM: GICv3 ITS: map device and LPIs to the ITS on physdev_op hypercall

["Jaggi, Manish" <Manish.Jaggi@cavium.com>]

Hi Julien,


On 1/31/2017 6:13 PM, Julien Grall wrote:
>
>
> On 31/01/17 10:29, Jaggi, Manish wrote:
>>>
>>> From: Xen-devel <xen-devel-bounces@lists.xen.org> on behalf of Andre 
>>> Przywara <andre.przywara@arm.com>
>>> Sent: Tuesday, January 31, 2017 12:01 AM
>>> To: Stefano Stabellini; Julien Grall
>>> Cc: xen-devel@lists.xenproject.org; Vijay Kilari
>>> Subject: [Xen-devel] [PATCH 09/28] ARM: GICv3 ITS: map device and 
>>> LPIs to the ITS on physdev_op hypercall
>>>
>> [snip]
>>>
>>>
>>>  int do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>>>  {
>>> +    struct physdev_manage_pci manage;
>>> +    u32 devid;
>>> +    int ret;
>>> +
>>> +    switch (cmd)
>>> +    {
>>
>> You might alos need to  PHYSDEVOP_pci_device_add hypercall also.
>>
>>> +        case PHYSDEVOP_manage_pci_add:
>>> +        case PHYSDEVOP_manage_pci_remove:
>>> +            if ( copy_from_guest(&manage, arg, 1) != 0 )
>>> +                return -EFAULT;
>>> +
>>> +            devid = manage.bus << 8 | manage.devfn;
>>> +            /* Allocate an ITS device table with space for 32 MSIs */
>>> +            ret = gicv3_its_map_guest_device(hardware_domain, 
>>> devid, devid, 5,
>>> +                                             cmd == 
>>> PHYSDEVOP_manage_pci_add);
>>
>> Based on 4.9 kernel, is the deivce ID plain sBDF or it is 
>> returnedfrom of_msi_map_rid /  iort_msi_map_rid ?
>> I believe there needs to be set this as requirement on the calle of 
>> hypercall.
>
> The requirement of the hypercall is already defined and cannot be 
> changed. So if it does not provide the correct information, then we 
> need to find another way to get the DeviceID.
>
Do you think sbdf and device ID are same ? If you recollect your 
comments last year sbdf != DeviceID.
for this series it has to be passed correctly otherwise ITS is programmed with wrong deviceID.
I suggest this series to include another way as well.
> In case of ACPI, we should be able to get those informations from the 
> IORT as the segment number is defined in the firmware tables. But for 
> Device Tree, we would need DOM0 and Xen to agree on the segment number.
>
Is there any agreement hypercall used with this series ?
> However, I am not sure whether we are going to need those hypercalls 
> when Xen will gain support of PCI. There are some discussion to let 
> Xen scanning the PCI devices, and therefore the hypercalls will be used.
>
> Today, the hypercall is called by Linux on ARM, but it might not be 
> the case in the future. If we decide to implement it today, it means 
> that we will not be able to remove it from Linux from compatibility 
> reasons.
>
> So I would be more in favor of having a per-platform list of devices 
> to support for the time being. So we can get GICv3 ITS working with 
> Device Tree until Xen gain support of PCI. Stefano, Andre, any opinions?
> Cheers,
>


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