> > Why? driver_probe_device() allows a driver to explicitly bind
> > to a specific device. What is conceptually wrong with allowing
> > that?
>
> Because that's not how a bus should work, and the fact that no other
> subsystem in the kernel does that might be a hint you are trying to do
> something a bit "wrong" here.
Let me try to succinctly as I can describe the problem we are trying to
solve here...
The vfio mechanism in the kernel (e.g. vfio-pci) allows devices to be
exposed user space (via file descriptors), enabling user space
drivers. So, for example to export an e1000 card to user space, I do
this:
echo 0001:03:00.0 > /sys/bus/pci/devices/0001:03:00.0/driver/unbind
echo 8086 10d3 > /sys/bus/pci/drivers/vfio-pci/new_id
The first step unbinds the target device (0001:03:00.0) from the normal
e1000 driver.
The second step causes the vfio-pci driver to bind to device 0001:03:00.0.
This second step tells vfio-pci that it now handles e1000 device IDs,
and the vfio-pci drivers registers with the PCI bus to handle '8086 10d3'.
That works, but it is ugly. We now have 2 active drivers handling
the same device type...which introduces various possible race conditions.
We never want vfio-pci to auto-bind to any new device that shows up
on the PCI bus. Binding a device to vfio-pci must be an explicit
action by an administrator.
You mentioned previously that user space can sort out the problem
of multiple drivers registered for handling the same device type.
That is true, but doesn't help here. We don't want vfio-pci
to handle _all_ e1000 cards, just explicitly selected e1000 cards.
We want the normal e1000 driver to be loaded and to bind to new
devices that may be hot-plugged.
There are 2 proposed mechanisms that have been put forth, both of
which you have now rejected:
1. sysfs_bind_only flag was proposed which would allow a vfio
driver (like vfio-pci) to only bind by explicit request through
the sysfs 'bind' file.
2. Have the vfio driver call driver_probe_device() to explicitly bind
a particular device instance to the driver. Only change we need
here is the EXPORT_SYMBOL.
Are you in principle opposed to any mechanism that would allow 2 drivers
to be resident/active and allow a sysadmin to explicitly bind a
particular device instance to the driver of their choice?
Thanks,
Stuart
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
