|
[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 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 :). So I'd suggest the following: - To make Dom0 run in this version of the patches, especially with platform devices, we allow MAPDs to propagate from Dom0. - We check whether this device has already been mapped. If yes, we map the virtual side and return. - If not mapped already, we possibly somehow sanitize the device ID (using some platform-specific function, for instance) and issue the MAPD and all the possible MAPTIs to the hardware ITS. We might avoid this in the future, when we have proper passthrough support in place. I am not sure why you would need per-platform code to sanitize the Device ID. I think a first approach is to trust all input from dom0, we can refine this later one by either reading the configuration space for PCI, for platform device we would need to come up for possibly a new hypercall (this could be discussed in a separate thread). So PCI devices would be mapped by the PHYSOPS hypercall as before, but platform devices would be handled via this way. I don't understand why you still want to implement physdevop hypercalls knowing that they will likely get ditched for ARM and don't provide all the information we need. It is not possible to know the DeviceID from RID without parsing DT and we don't have the number of MSI supported in hand. So it makes no sense to implement those hypercalls. Does this make sense? Looking at the implementation of gicv3_its_map_guest_device, for each virtual MAPD issued, you will issue one host MAPD command, one host MAPTI and INV per event. This will potentially fill up the host command queue and takes time to executed (imagine a SYNC at the end). So what will you do if the queue is full? Xen is not preemptible and if you busy loop, dom0 may have its watchdog raised or the RCU stalls. Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |