PCI "full controller" passthrough for Windows HVM still not working

[tonsimple]

Qubes OS version (e.g., R3.2):

3.2

Affected TemplateVMs (e.g., fedora-23, if applicable):

dom0?
Windows 7 HVM

---

Expected behavior:

Assigning full USB controller to win7 VM with pci_strictreset set to false will work and allow using a USB device

Actual behavior:

Attempt to assign a USB controller fail with various interesting (but useless) results.

First, without pci_strictreset none of the controllers I have could even begin to be assigned.
(but that is expected, same thing happens for "normal" VMs and pci_strictreset was a sufficient cure.)

Attempting to assign a NEC USB 3.0 controller:
VM fails to start, libxenlight reports "unable to create domain win7"

ASMedia USB3.0 - same

Intel USB 3.0 controller
the most interesting result
The VM starts and controller is found, but it is found as a "detachable" device.
Installation of Intel drivers does not cause it to be detected properly (the icon changes from windows device warning sign to "normal usb controller" sign but it still remains a "detachable device")

Attempts to connect a USB device to the physical port, however, lead to literally nothing (device is not detected by the windows VM as if no controller was present)

Steps to reproduce the behavior:

Have a created Windows HVM with Qubes tools installed

Shut it down.

Assign a USB 3.0 pcie controller to it via VM manager

Start VM

General notes:

Building an elaborate workaround for printing that involves a separate physical fanless PC with windows XP embedded so that I can get a bunch of USB devices forwarded over network to the windows VM (therere's software for forwarding USB ports like that, hope it works)

---

Related issues:

I humbly suspect that closed issue #1659 is related

[marmarek]

What Xen version do you have (rpm -q xen)? There were some more fixes in 4.6.3-25 (and 4.6.4-25) which is still in testing repository.
For non-intel USB controller - check /var/log/libvirt/libxl/libxl-driver.log and /var/log/xen/console/hypervisor.log after failed startup - maybe some clue will be there.

[marmarek]

What Xen version do you have (rpm -q xen)? There were some more fixes in 4.6.3-25 (and 4.6.4-25) which is still in testing repository.
For non-intel USB controller - check /var/log/libvirt/libxl/libxl-driver.log and /var/log/xen/console/hypervisor.log after failed startup - maybe some clue will be there.

[tonsimple]

xen-4.6.3-24.fc23.x86_64

I'll try re-doing everything and getting those logs around next week (my qubes desktop is current making good use of those usb controllers in other appvms)

[tonsimple]

xen-4.6.3-24.fc23.x86_64

I'll try re-doing everything and getting those logs around next week (my qubes desktop is current making good use of those usb controllers in other appvms)

[tonsimple]

Managed to workaround via fedora-24's usbip module (which appears fairly broken btw) and usbip windows client (also broken)
Workaround works only if printer sharing service is running in usbvm and if usbip is attached to device driver before printer sharing starts up

Oh, and I needed to enable networking between my USBvm and my windows HVM (not really a biggie since neither is allowed into "the internet at large")

Will probs work like this until PCI passthrough or, perhaps even better, qubes-usb-proxy, start working for windows HVMs

EDITED TO ADD:
usbip on Debian 8 is much superior (does not require rebooting usbvm if windows hvm was rebooted, which was oddball quirk of Fedora's usbip), with a little bit of strange tweaks allows sharing of both scanner and printer with windows 7 hvm

Also successfully shared a webcam as a test (which Fedora's usbip implementation could not cope with no matter what I tried)

The only oddity on Debian usbip is that early on (in rc.local that means) you need to share every usbip-bound device with the usbvm itself (localhost) and then un-share it

in order for windows usbip client to connect, windows usbip MUST wait at least 15 seconds after VM startup before attempting connection. Otherwise both client and server hang or crash

rc.local for sharing a Canon multifunction scanner+printer device is (posting for qubes users looking to share usb devices with VMs in cases where "standard" measures don't work and inter-appvm networking is acceptable risk)
####
modprobe vhci-hcd
modprobe usbip-core
modprobe usbip-host
#NB, usb device specified in -b will likely be different
usbip bind -b 2-10
sleep 1
#usbip daemon starts here, not earlier
sudo usbipd -D
sleep 1
#this is the strange part that windows usbip from link above needs, for some reason
usbip --debug attach -r 127.0.0.1 -b 2-10 &> /dev/null
sleep 1
usbip detach -p 0 &> /dev/null
####

[tonsimple]

Managed to workaround via fedora-24's usbip module (which appears fairly broken btw) and usbip windows client (also broken)
Workaround works only if printer sharing service is running in usbvm and if usbip is attached to device driver before printer sharing starts up

Oh, and I needed to enable networking between my USBvm and my windows HVM (not really a biggie since neither is allowed into "the internet at large")

Will probs work like this until PCI passthrough or, perhaps even better, qubes-usb-proxy, start working for windows HVMs

EDITED TO ADD:
usbip on Debian 8 is much superior (does not require rebooting usbvm if windows hvm was rebooted, which was oddball quirk of Fedora's usbip), with a little bit of strange tweaks allows sharing of both scanner and printer with windows 7 hvm

Also successfully shared a webcam as a test (which Fedora's usbip implementation could not cope with no matter what I tried)

The only oddity on Debian usbip is that early on (in rc.local that means) you need to share every usbip-bound device with the usbvm itself (localhost) and then un-share it

in order for windows usbip client to connect, windows usbip MUST wait at least 15 seconds after VM startup before attempting connection. Otherwise both client and server hang or crash

rc.local for sharing a Canon multifunction scanner+printer device is (posting for qubes users looking to share usb devices with VMs in cases where "standard" measures don't work and inter-appvm networking is acceptable risk)
####
modprobe vhci-hcd
modprobe usbip-core
modprobe usbip-host
#NB, usb device specified in -b will likely be different
usbip bind -b 2-10
sleep 1
#usbip daemon starts here, not earlier
sudo usbipd -D
sleep 1
#this is the strange part that windows usbip from link above needs, for some reason
usbip --debug attach -r 127.0.0.1 -b 2-10 &> /dev/null
sleep 1
usbip detach -p 0 &> /dev/null
####