On Fri, 22 Jan 2021 16:04:21 -0400 Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: > On Fri, Jan 22, 2021 at 12:25:03PM -0700, Alex Williamson wrote: > > > In this way, we'll use the HW vendor driver core to manage the lifecycle > > > of these devices. This is reasonable since only the vendor driver knows > > > exactly about the status on its internal state and the capabilities of > > > its acceleratots, for example. > > > > But mdev provides that too, or the vendor could write their own vfio > > Not really, mdev has a completely different lifecycle model that is > not very compatible with what is required here. > > And writing a VFIO driver is basically what this does, just a large > portion of the driver is reusing code from the normal vfio-pci cases. I think you cut out an important part of Alex' comment, so let me repost it here: "But mdev provides that too, or the vendor could write their own vfio bus driver for the device, this doesn't really justify or delve deep enough to show examples beyond "TODO" remarks for a vendor driver actually interacting with vfio-pci-core in an extensible way. One of the concerns of previous efforts was that it's trying to directly expose vfio-pci's implementation as an API for vendor drivers, I don't really see that anything has changed in that respect here." I'm missing the bigger picture of how this api is supposed to work out, a driver with a lot of TODOs does not help much to figure out whether this split makes sense and is potentially useful for a number of use cases, or whether mdev (even with its different lifecycle model) or a different vfio bus driver might be a better fit for the more involved cases. (For example, can s390 ISM fit here?)
