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

From: Shanker Donthineni <shankerd@codeaurora.org>
To: Julien Grall <julien.grall@arm.com>,
	"Jaggi, Manish" <Manish.Jaggi@cavium.com>,
	Andre Przywara <andre.przywara@arm.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Cc: xen-devel@lists.xenproject.org, "Nair,
	Jayachandran" <Jayachandran.Nair@cavium.com>,
	Vijay Kilari <vijay.kilari@gmail.com>,
	"Kapoor, Prasun" <Prasun.Kapoor@cavium.com>
Subject: Re: [PATCH 09/28] ARM: GICv3 ITS: map device and LPIs to the ITS on physdev_op hypercall
Date: Fri, 24 Feb 2017 13:57:36 -0600	[thread overview]
Message-ID: <fb016299-4ca7-6ce9-e993-5d02e0ee6e7b@codeaurora.org> (raw)
In-Reply-To: <6478568b-a9e9-e909-34bf-880bd25208a8@arm.com>

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@lists.xen.org
https://lists.xen.org/xen-devel
