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 -- 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
