On 7/14/2016 8:03 PM, Alex Williamson wrote: >> 2. Add an owner_pid to struct vfio_group and make sure in vfio_group_get_device_fd that >> > the PFs vfio_group is owned by the same process as the one that is trying to get a fd for a VF. > This only solves a very specific use case, it doesn't address any of > the issues where the VF struct device in the host kernel might get > bound to another driver. The current patch uses driver_override to make the kernel use VFIO for all the new VFs. It still allows the host kernel to bind them to another driver, but that would require an explicit action on the part of the administrator. Don't you think that is enough? Do you think we should also take a reference on the VFIO devices to prevent an administrator from unbinding them? > Also is the pid really what we want to attach > ownership to? What if the owner of the PF wants to assign the VF to a > peer VM, not to a nested VM? It seems like there's an entire aspect of > owning and being able to grant ownership of a device to a user or group > missing. In order to support assigning to a peer VM, maybe we can do something a little different. What if we add a ioctl to enable SR-IOV, and the new ioctl would return an open fd for the VFIO group of each VF? Other attempts to open these groups by other processes would fail because the groups would already be open. The process that enabled SR-IOV could still pass these fds to other processes if needed, allowing other VMs to use them. What do you think? 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
