On Thu, Feb 11, 2021 at 08:47:03AM +0000, Christoph Hellwig wrote: > On Wed, Feb 03, 2021 at 09:54:48AM -0400, Jason Gunthorpe wrote: > > If people are accepting that these device-specific drivers are > > required then we need to come to a community consensus to decide what > > direction to pursue: > > > > * Do we embrace the driver core and use it to load VFIO modules like a > > normal subsytem (this RFC) > > > > OR > > > > * Do we make a driver-core like thing inside the VFIO bus drivers and > > have them run their own special driver matching, binding, and loading > > scheme. (May RFC) > > > > Haven't heard a 3rd option yet.. > > The third option would be to use the driver core to bind the VFIO > submodules. Define a new bus for it, which also uses the normal PCI IDs > for binding, and walk through those VFIO specific drivers when vfio_pci > is bound to a device. That would provide a pretty clean abstraction > and could even keep the existing behavior of say bind to all VGA devices > with an Intel vendor ID (even if I think that is a bad idea). I think of this as some variant to the second option above. Maximally using the driver core to make subdrivers still means the VFIO side needs to reimplement all the existing matcher logic for PCI (and it means we don't generalize, so future CXL/etc, will need more VFIO special code) It has to put this stuff on a new special bus and somehow make names and match tables for it. It also means we'd have to somehow fix vfio-pci to allow hot plug/unplug of the subdriver. The driver core doesn't really run synchronously for binding, so late binding would have to be accommodated somehow. It feels like adding a lot of complexity for very little gain to me. Personally I dislike the subdriver direction of the May RFC quite a bit, it has a lot of unfixable negatives for the admin side. The first option does present some challenges for userspace but I belive we can work through them. Jason
