Re: mechanism to allow a driver to bind to any device

[Konrad Rzeszutek Wilk <konrad.wilk-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>]

On Wed, Mar 26, 2014 at 11:06:02PM +0800, Alexander Graf wrote:
> 
> 
> > Am 26.03.2014 um 22:40 schrieb Konrad Rzeszutek Wilk <konrad.wilk-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>:
> > 
> >> On Wed, Mar 26, 2014 at 01:40:32AM +0000, Stuart Yoder wrote:
> >> Hi Greg,
> >> 
> >> We (Linaro, Freescale, Virtual Open Systems) are trying get an issue
> >> closed that has been perculating for a while around creating a mechanism
> >> that will allow kernel drivers like vfio can bind to devices of any type.
> >> 
> >> This thread with you:
> >> http://www.spinics.net/lists/kvm-arm/msg08370.html
> >> ...seems to have died out, so am trying to get your response
> >> and will summarize again.  Vfio drivers in the kernel (regardless of
> >> bus type) need to bind to devices of any type.  The driver's function
> >> is to simply export hardware resources of any type to user space.
> >> 
> >> There are several approaches that have been proposed:
> > 
> > You seem to have missed the one I proposed.
> >> 
> >>   1.  new_id -- (current approach) the user explicitly registers
> >>       each new device type with the vfio driver using the new_id
> >>       mechanism.
> >> 
> >>       Problem: multiple drivers will be resident that handle the
> >>       same device type...and there is nothing user space hotplug
> >>       infrastructure can do to help.
> >> 
> >>   2.  "any id" -- the vfio driver could specify a wildcard match
> >>       of some kind in its ID match table which would allow it to
> >>       match and bind to any possible device id.  However,
> >>       we don't want the vfio driver grabbing _all_ devices...just the ones we
> >>       explicitly want to pass to user space.
> >> 
> >>       The proposed patch to support this was to create a new flag
> >>       "sysfs_bind_only" in struct device_driver.  When this flag
> >>       is set, the driver can only bind to devices via the sysfs
> >>       bind file.  This would allow the wildcard match to work.
> >> 
> >>       Patch is here:
> >>       https://lkml.org/lkml/2013/12/3/253
> >> 
> >>   3.  "Driver initiated explicit bind" -- with this approach the
> >>       vfio driver would create a private 'bind' sysfs object
> >>       and the user would echo the requested device into it:
> >> 
> >>       echo 0001:03:00.0 > /sys/bus/pci/drivers/vfio-pci/vfio_bind
> >> 
> >>       In order to make that work, the driver would need to call
> >>       driver_probe_device() and thus we need this patch:
> >>       https://lkml.org/lkml/2014/2/8/175
> > 
> > 4). Use the 'unbind' (from the original device) and 'bind' to vfio driver.
> 
> This is approach 2, no?
> 
> > 
> > Which I think is what is currently being done. Why is that not sufficient?
> 
> How would 'bind to vfio driver' look like?

you echo the BDF to a 'new_slot' to setup an pci match entry (so that it
can lookup from the BDF the device/vendor id). Then you echo the
BDF to the 'bind'.

> 
> > The only thing I see in the URL is " That works, but it is ugly."
> > There is some mention of race but I don't see how - if you do the 'unbind'
> > on the original driver and then bind the BDF to the VFIO how would you get
> > a race?
> 
> Typically on PCI, you do a
> 
>   - add wildcard (pci id) match to vfio driver
>   - unbind driver
>   -> reprobe
>   -> device attaches to vfio driver because it is the least recent match
>   - remove wildcard match from vfio driver
> 
> If in between you hotplug add a card of the same type, it gets attached to vfio - even though the logical "default driver" would be the device specific driver.

But that would not happen if you use BDF. So if you switch from using
device/vendor id then you don't have this problem.
> 
> 
> Alex
> 
> > 
> >> 
> >> Would like your comment on these options-- option #3 is preferred
> >> and is literally a 2 line patch.
> >> 
> >> Thanks,
> >> Stuart
> >> _______________________________________________
> >> iommu mailing list
> >> iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/iommu