Hi Alex, It seems that I'm missing something because I fail to see how the sysfs interface solves any of the problems you've pointed out in the current code. Can you please clarify what you want us to do on the kernel side besides moving to the sysfs interface? How do we prevent the administrator from unbinding the VFs from vfio and binding them to the default driver? How does the new model prevent the administrator from assigning the VFs to other VM? Thanks Ilya -----Original Message----- From: Alex Williamson [mailto:alex.williamson@xxxxxxxxxx] Sent: Monday, July 25, 2016 6:08 PM To: Haggai Eran <haggaie@xxxxxxxxxxxx> Cc: Tian, Kevin <kevin.tian@xxxxxxxxx>; Ilya Lesokhin <ilyal@xxxxxxxxxxxx>; kvm@xxxxxxxxxxxxxxx; linux-pci@xxxxxxxxxxxxxxx; bhelgaas@xxxxxxxxxx; Noa Osherovich <noaos@xxxxxxxxxxxx>; Or Gerlitz <ogerlitz@xxxxxxxxxxxx>; Liran Liss <liranl@xxxxxxxxxxxx> Subject: Re: [PATCH v2 0/2] VFIO SRIOV support 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 linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
