Hello,
On Wed, Mar 26, 2014 at 2:40 AM, Stuart Yoder <stuart.yo...@freescale.com>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: > > 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. > > Of note is that new_id doesn't work particularly well for platform devices. Before trying any of the other two solutions, a nasty hack was applied on the device tree used with the system in order to let vfio-platform match with a specific device, which is certainly not an acceptable solution. Implementing wildcard matching quickly reveals the problems mentioned, which motivates the other two approaches. > 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 > > > Would like your comment on these options-- option #3 is preferred > and is literally a 2 line patch. > I would definitely agree with approach #3, for which Kim has already provided a patch. Not having this would make using VFIO with platform devices really inelegant and strange. > > Thanks, > Stuart > -- Antonios Motakis Virtual Open Systems
_______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu