I have a controller that I pass through for some USB devices that don't work in linux and I just bind it out early because it's easier than binding out the drivers that attach to the devices on the controller and then don't work and won't unbind. It sounds like you may have a similar problem and looking at what you described I'd say your boot solution may not work because you don't have vfio-pci in your initramfs. Add the following to your dracut.conf but bear in mind I don't use fedora or dracut so you might need to find the right syntax/file. Hopefully your init script will work after that - stick some messages in dmesg with it (command is logger on my system).
drivers+="vfio-pci vfio vfio-virqfd vfio-iommu-type1"
As an alternative you can try the pci-stub module which is probably a good idea if your controller is misbehaving and won't unbind post-boot. It is simpler and won't power save the controller plus I think in fedora it might be compiled into the kernel by default on some versions in which case you can avoid all the above and definitely beat the xhci drivers to binding to the controller by adding the following to your kernel command line:
There's a tonne of other ways to do this but those should work and keep working. Other things to check are that any drives aren't auto-mounted before you try the post-boot unbind and that any devices on the usb bus unbind properly. I'd like to think unbinding the host driver would shut them all down - but that doesn't always happen and you say it works after a clean no-device reboot plus things have their own power source and generic drivers don't work with everything. One way to do this is to find the directory for your hub in sysfs and unbind them one by one then rebind them and see if they play ball (don't forget lsusb -vt).
The final thing to check thoroughly is that your controller is suitable for passing through. It should obviously have it's own IOMMU group (or be grouped only with things your passing through), but double check with lspci -tv that it's not under a root bridge with something else and if it is move the card or switch off the something else. Lots of things can break the isolation like shared IRQs or PCI power saving/AER/Hotplug and moving cards around may help .. but your controller/mboard may just not isolate themselves sufficiently to passthrough without silly constraints.
If it doesn't just work I would consider your options though. Most of my built in USB controllers have hard wired IO ports so would be asking for trouble on pass through (of the intermittent variety) plus if it has the drivers Linux does a much better job of scheduling/hangs/resets/ACPI/etc. than windows or an isolated linux VM plus usb passthrough (i.e. -usb -usb_host .... for qemu) costs basically nothing important as USB drives don't have the throughput (unless you've got some prototype full speed USB 3.1 stuff lying around). I've had no troubles using passthrough with USB-Sticks / drives - I even re-installed the firmware on a USB drive that I was passing through. I wouldn't try that at home .. but installing windows on unviolated bare metal risks the entire system as far as I'm concerned.
On 25/03/16 17:23, thibaut noah wrote: