> Am 26.03.2014 um 22:40 schrieb Konrad Rzeszutek Wilk <konrad.w...@oracle.com>: > >> 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? > 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. 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@lists.linux-foundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/iommu _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
