From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-db5eur01on0050.outbound.protection.outlook.com ([104.47.2.50]:22611 "EHLO EUR01-DB5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752562AbcGYIJX (ORCPT ); Mon, 25 Jul 2016 04:09:23 -0400 Subject: Re: [PATCH v2 0/2] VFIO SRIOV support To: Alex Williamson , "Tian, Kevin" References: <1466338617-43027-1-git-send-email-ilyal@mellanox.com> <20160620113728.74ed79f3@ul30vt.home> <20160621094537.4416cbce@t450s.home> <20160714110341.7716c619@t450s.home> <20160718153428.6b988539@t450s.home> <20160719091017.4c23244f@t450s.home> <20160719134336.79d24af9@t450s.home> CC: Ilya Lesokhin , "kvm@vger.kernel.org" , "linux-pci@vger.kernel.org" , "bhelgaas@google.com" , Noa Osherovich , Or Gerlitz , Liran Liss From: Haggai Eran Message-ID: <613c4470-d899-2698-dfe5-9dbb2388787e@mellanox.com> Date: Mon, 25 Jul 2016 10:53:56 +0300 MIME-Version: 1.0 In-Reply-To: <20160719134336.79d24af9@t450s.home> Content-Type: text/plain; charset="windows-1252" Sender: linux-pci-owner@vger.kernel.org List-ID: On 7/19/2016 10:43 PM, Alex Williamson wrote: > Thinking about this further, it seems that trying to create this IOV > enablement interface through a channel which is explicitly designed to > interact with an untrusted and potentially malicious user is the wrong > approach. We already have an interface for a trusted entity to enable > VFs, it's through pci-sysfs. Therefore if we were to use something like > libvirt to orchestrate the lifecycle of the VFs, I think we remove a > lot of the problems. In this case QEMU would virtualize the SR-IOV > capability (maybe this is along the lines of what Kevin was thinking), > but that virtualization would take a path out through the QEMU QMP > interface to execute the SR-IOV change on the device rather than going > through the vfio kernel interface. A management tool like libvirt > would then need to translate that into sysfs operations to create the > VFs and do whatever we're going to do with them (device_add them back > to the VM, make them available to a peer VM, make them available to > the host *gasp*). VFIO in the kernel would need to add SR-IOV > support, but the only automatic SR-IOV path would be to disable IOV > when the PF is released, enabling would only occur through sysfs. We > would probably need a new pci-sysfs interface to manage the driver for > newly created VFs though to avoid default host drivers > (sriov_driver_override?). In this model QEMU is essentially just > making requests to other userspace entities to perform actions and how > those actions are performed can be left to userspace policy, not kernel > policy. I think this would still satisfy the development use case, the > enabling path just takes a different route where privileged userspace > is more intimately involved in the process. Thoughts? Thanks, I understand the desire to use a different interface such as sysfs for the trusted user-space component. I'm not sure though how using sriov_driver_override solves the issues we have been discussing. After SR-IOV is enabled by libvirt, it is still possible for the administrator (or another trusted daemon racing with libvirt) to open the VFs with VFIO before libvirt had a chance to open them and send them to QEMU. Are you okay with that? Thanks, Haggai