On Fri, Mar 19, 2021 at 05:07:49PM -0300, Jason Gunthorpe wrote:
> The way the driver core works is to first match against the already
> loaded driver list, then trigger an event for module loading and when
> new drivers are registered they bind to unbound devices.
>
> So, the trouble is the event through userspace because the kernel
> can't just go on to use vfio_pci until it knows userspace has failed
> to satisfy the load request.
>
> One answer is to have userspace udev have the "hook" here and when a
> vfio flavour mod alias is requested on a PCI device it swaps in
> vfio_pci if it can't find an alternative.
>
> The dream would be a system with no vfio modules loaded could do some
>
> echo "vfio" > /sys/bus/pci/xxx/driver_flavour
>
> And a module would be loaded and a struct vfio_device is created for
> that device. Very easy for the user.
Maybe I did not communicate my suggestion last week very well. My
idea is that there are no different pci_drivers vs vfio or not,
but different personalities of the same driver.
So the interface would still look somewhat like your suggestion above,
although I'd prefer something like:
echo 1 > /sys/bus/pci/xxx/use_vfio
How would the flow look like for the various cases?
a) if a driver is bound, and it supports the enable_vfio method that
is called, and everything is controller by the driver, which uses
symbols exorted from vfio/vfio_pci to implement the functionality
b) if a driver is bound, but does not support the enable_vfio method
it is unbound and vfio_pci is bound instead, continue at c)
c) use the normal current vfio flow
do the reverse on a
echo 0 > /sys/bus/pci/xxx/use_vfio
