[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



On 24/02/2017 19:57, Shanker Donthineni wrote:
Hi Julien,

Hi Shanker,


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.

I guess this can work. Note that, on a separate thread (see [1]), I suggested to decouple the virtual DeviceID to the physical one for DOM0 to simply the generation of the IORT.

So we would have to be a bit more clever here. But that's probably a separate subject and can go in Xen in separate series.

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;
+


Cheers,

[1] https://lists.xen.org/archives/html/xen-devel/2017-02/msg02782.html

--
Julien Grall

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.