On Tue, Dec 13, 2022 at 10:01:03AM -0400, Jason Gunthorpe wrote: > > So now we need to write a vfio shim for every function even if there > > is absolutely nothing special about that function? Migrating really > > is the controlling functions behavior, and writing a new vfio bit > > for every controlled thing just does not scale. > > Huh? "does not scale?" We are looking at boilerplates of around 20-30 > lines to make a VFIO driver for a real PCI device. Why is that even > something we should worry about optimizing? But we need a new driver for every controlled function now, which is very different from the classic VFIO model where we had one vfio_pci. > And when you get into exciting future devices like SIOV you already > need to make a special VFIO driver anyhow. You need to special support for it. It's probably not another Linux driver but part of the parent one, though. > So far 100% of the drivers that have been presented, including the two > RFC ones, have entanglements between live migration and vfio. Shifting > things to dev/live_migration doesn't make the "communication problem" > away, it just shifted it into another subsystem. The main entanglement seems to be that it needs to support a vfio interface for live migration while the actual commands go to the parent device. > This is my point, I've yet to even see a driver that meets your > theoretical standard that it can exist without vfio entanglement. It can't right now due to the VFIO design. > > While creating the VFs from the PF driver makes a lot more sense, > > remember that vfio is absolutely not the only use case for VFs. > > There are plenty use cases where you want to use them with the normal > > kernel driver as well. So the interface to create VFs needs a now > > to decide if it should be vfio exported, or use the normal kernel > > binding. > > Yes, that is why this problem has been open for so long. Fixing it > well requires some reconsideration of how the driver core works :( > > It is worse than just VFIO vs one kernel driver, like mlx5 could spawn > a controlled function that is NVMe, VDPA, mlx5, virtio-net, VFIO, > etc. This seems to violate the PCIe spec, which says: "All VFs associated with a PF must be the same device type as the PF, (e.g., the same network device type or the same storage device type.)", which is also enforced by not allowing to read vendor/device/class fields from VFs. (not that I'm arguing that this is a good limit, but that's how PCIe does it). > When we create the function we really want to tell the device what > kind of function it is, and that also tells the kernel what driver > should be bound to it. I'd rather have different ways to probe by passing a "kind" or "type" argument along the device IDs during probing. E.g. "driver" and "vfio", and then only match for the kind the creator of the device added them to the device model for. > mlx5 even has weird limitations, like a controlled function that is > live migration capable has fewer features than a function that is > not. So the user must specify what parameters it wants the controlled > function to have.. I don't think that is weird. If you want to live migrate, you need to a) make sure the feature set is compatible with the other side b) there is only state that actually is migratable so I'd expect that for any other sufficiently complex device. NVMe for sure will have limits like this.
