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