[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 09/28] ARM: GICv3 ITS: map device and LPIs to the ITS on physdev_op hypercall
Hi Julien, On 1/31/2017 7:16 PM, Julien Grall wrote: > On 31/01/17 13:19, Jaggi, Manish wrote: >> 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@xxxxxxxxxxxxx> on behalf of Andre >>>>> Przywara <andre.przywara@xxxxxxx> >>>>> Sent: Tuesday, January 31, 2017 12:01 AM >>>>> To: Stefano Stabellini; Julien Grall >>>>> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; 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 would be >> programmed incorrectly. >> I suggest this series to include another way as well. > > Thank you sherlock, if you had read my e-mail entirely you would have noticed > I never said sbdf == DeviceID and actually provided insight on the problem > and suggest solutions. > If you please read 4 lines above I wrote sbdf != DeviceID. > I would recommend you to do the same in the future. It would help to get the > code much faster in Xen. > >> >>> 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 ? > > From xen/include/public/physdev.h > > struct physdev_manage_pci { > /* IN */ > uint8_t bus; > uint8_t devfn; > }; > > struct physdev_manage_pci_ext { > /* IN */ > uint8_t bus; > uint8_t devfn; > unsigned is_extfn; > unsigned is_virtfn; > struct { > uint8_t bus; > uint8_t devfn; > } physfn; > }; > > Let me know how you could encode a DeviceID in those hypercalls. > If you please go back to your comment where you wrote "we need to find another way to get the DeviceID", I was referring that we should add that another way in this series so that correct DeviceID is programmed in ITS. > Cheers, > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |