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

[Shanker Donthineni <shankerd@codeaurora.org>]

Hi Julien,


On 02/28/2017 12:29 PM, Julien Grall wrote:
>
>
> On 27/02/17 17:20, Andre Przywara wrote:
>> Hi,
>
> Hi Andre,
>
>> On 24/02/17 19:57, Shanker Donthineni wrote:
>>> 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.
>>
>> But this breaks our assumption that no ITS commands can ever be
>> propagated at guest's runtime, which is the cornerstone of this series.
>> I agree that this is unfortunate and allowing it would simplify things,
>> but after long discussions we came to the conclusion that it's not
>> feasible to do so:
>> A malicious guest could flood the virtual ITS with MAPD commands. Xen
>> would need to propagate those to the hardware, which relies on the host
>> command queue to have free slots, which we can't guarantee. For
>> technical reasons we can't reschedule the guest (because this is an MMIO
>> trap), also the domain actually triggering the "final" MAPD might not be
>> the culprit, but an actual legitimate user.
>> So we agreed upon issuing all hardware ITS commands before a guest
>> actually starts (DomUs), respectively on hypercalls for Dom0.
>> I think we can do exceptions for Dom0, since it's not supposed to be
>> malicious.
>
> Thank you for summarizing the problem :).
>

Direct VLPI injection feature is included in GICv4 architecture. A new 
set of VLPI commands are introduced to map ITS vpend/vprop tables, ITTE 
setup, and maintenance operations for VLPIs. In case of direct VLPI 
injection, domU/dom0 LPI commands are mapped to VLPI commands. Some of 
these commands must be applied to a real ITS hardware whenever XEN 
receives the ITS commands during runtime.


Any thought on this, how we are going to support a direct VLPI injection 
without prolongating dom0/domU ITS commands to hardware at runtime?

-- 

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