On Mon, 25 Jul 2016 10:53:56 +0300 Haggai Eran <haggaie@xxxxxxxxxxxx> wrote: > 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? If a privileged entity like libvirt is creating VFs on behalf of a user, it's going to be that entity's responsibility to claim ownership of all those created VFs. sriov_driver_override is just one suggestion that might help facilitate that. Others might be necessary, but ultimately it's not the kernel's problem to work out which entity gets to take ownership of those devices, that's a userspace problem, just as it is already today. Thanks, Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
