From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: mechanism to allow a driver to bind to any device Date: Wed, 26 Mar 2014 12:24:40 -0400 Message-ID: <20140326162440.GA21368@phenom.dumpdata.com> References: <20140214222716.GA11838@kroah.com> <20140215024725.GA2542@kroah.com> <7043e1edd9974de590dcb392cd8aff14@DM2PR03MB352.namprd03.prod.outlook.com> <20140215173348.GA8056@kroah.com> <20140220224337.GA20097@kroah.com> <54cd150235ba4954becdd12f725c5ebd@DM2PR03MB352.namprd03.prod.outlook.com> <20140326144025.GA18387@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Alexander Graf Cc: "kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "jan.kiszka-kv7WeFo6aLtBDgjK7y7TUQ@public.gmane.org" , "will.deacon-5wv7dgnIgG8@public.gmane.org" , Stuart Yoder , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Michal Hocko , Bjorn Helgaas , Varun Sethi , "kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg@public.gmane.org" , "Rafael J. Wysocki" , Guenter Roeck , Dmitry Kasatkin , Joe Perches , Scott Wood , Antonios Motakis , "tech-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org" , Toshi Kani , Greg KH , "a.rigo-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org" , iommu-cunTk1MwBs8@public.gmane.org List-Id: iommu@lists.linux-foundation.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 : > > > >> 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