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

[Shanker Donthineni <shankerd@xxxxxxxxxxxxxx>]

Hi Julien,


On 01/31/2017 10:18 AM, Julien Grall wrote:
> On 31/01/17 16:02, Jaggi, Manish wrote:
> > On 1/31/2017 8:47 PM, Julien Grall wrote:
> > > On 31/01/17 14:08, Jaggi, Manish wrote:
> > > > 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:
> > > > 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.
> > > This is not the first time I am saying this, just saying "we should 
> > > add that another way..." is not helpful. You should also provide 
> > > some details on what you would do.
> > Julien, As you suggested we need to find another way, I assumed you 
> > had something in mind.
> I gave suggestions on my e-mail but you may have missed it...
>
> > Since we both agree that sbdf!=deviceID, the current series of ITS 
> > patches will program the incorrect deviceID so there is a need to
> > have a way to map sbdf with deviceID in xen.
> >
> > One option could be to add a new hypercall to supply sbdf and 
> > deviceID to xen.
> ... as well as the part where I am saying that I am not in favor to
> implement an hypercall temporarily, and against adding a new hypercall
> for only a couple of weeks. As you may know PHYSDEV hypercall are part
> of the stable ABI and once they are added they cannot be removed.
>
> So we need to be sure the hypercall is necessary. In this case, the
> hypercall is not necessary as all the information can be found in the
> firmware tables. However this is not implemented yet and part of the
> discussion on PCI Passthrough (see [1]).
>
> We need a temporary solution that does not involve any commitment on the
> ABI until Xen is able to discover PCI.
Why can't  we handle ITS device creation whenever a virtual ITS driver 
receives the MAPD command from dom0/domU. In case of dom0, it's straight 
forward dom0 always passes the real ITS device through MAPD command. 
This way we can support PCIe devices without hard-coded MSI(x) limit 32, 
and platform devices transparently. I used the below code to platform 
and PCIe device MSI(x) functionality on QDF2400 server platform.
@@ -383,10 +384,17 @@ static int its_handle_mapd(struct virt_its *its, 
uint64_t *cmdptr)
     int size = its_cmd_get_size(cmdptr);
     bool valid = its_cmd_get_validbit(cmdptr);
     paddr_t itt_addr = its_cmd_mask_field(cmdptr, 2, 0, 52) & 
GENMASK(51, 8);
+    int ret;

     if ( !its->dev_table )
         return -1;

+    size = size < 4 ? 4 : size;
+    ret = gicv3_its_map_guest_device(hardware_domain, devid, devid, 
size + 1,
+                                     valid);
+    if (ret < 0)
+        return ret;
+


--
Shanker Donthineni
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.


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