On Thu, Oct 05, 2023 at 01:49:54AM -0700, Christoph Hellwig wrote: > But for all the augmented vfio use cases it doesn't, for them the > augmented vfio functionality is an integral part of the core driver. > That is true for nvme, virtio and I'd argue mlx5 as well. I don't agree with this. I see the extra functionality as being an integral part of the VF and VFIO. The PF driver is only providing a proxied communication channel. It is a limitation of PCI that the PF must act as a proxy. > So we need to stop registering separate pci_drivers for this kind > of functionality, and instead have an interface to the driver to > switch to certain functionalities. ?? We must bind something to the VF's pci_driver, what do you imagine that is? > E.g. for this case there should be no new vfio-virtio device, but > instead you should be able to switch the virtio device to an > fake-legacy vfio mode. Are you aruging about how we reach to vfio_register_XX() and what directory the file lives? I don't know what "fake-legacy" even means, VFIO is not legacy. There is alot of code in VFIO and the VMM side to take a VF and turn it into a vPCI function. You can't just trivially duplicate VFIO in a dozen drivers without creating a giant mess. Further, userspace wants consistent ways to operate this stuff. If we need a dozen ways to activate VFIO for every kind of driver that is not a positive direction. Basically, I don't know what you are suggesting here. We talked about this before, and my position is still the same. Continuing to have /dev/vfio/XX be the kernel uAPI for the VMM to work with non-mediated vPCI functions with live migration is the technically correct thing to do. Why wouldn't it be? > Similarly for nvme. We'll never accept a separate nvme-live migration > vfio driver. This functionality needs to be part of the nvme driver, > probed there and fully controlled there. We can debate where to put the files when the standard is done, but the end of the day it needs to create /dev/vfio/XXX. Jason
