USB Passthrough not working for Windows 7 guest

Bug #685096 reported by Max Power
126
This bug affects 20 people
Affects Status Importance Assigned to Milestone
QEMU
Won't Fix
Undecided
Unassigned
qemu (Debian)
Incomplete
Undecided
Unassigned
qemu (Ubuntu)
Expired
Low
Unassigned

Bug Description

USB Passthrough from host to guest is not working for a 32-bit Windows 7 guest, while it works perfectly for a 32-bit Windows XP guest.

The device appears in the device manager of Windows 7, but with "Error code 10: device cannot start". I have tried this with numerous USB thumbdrives and a USB wireless NIC, all with the same result. The device name and functionality is recognized, so at least some USB negotiation is taking place.

I am trying this with the latest git-pull of QEMU-KVM.

The command line to launch qemu-kvm for win7 is:
sudo /home/user/local_install/bin/qemu-system-x86_64 -cpu core2duo -m 1024 -smp 2 -vga std -hda ./disk_images/win7.qcow -vnc :1 -boot c -usb -usbdevice tablet -usbdevice host:0781:5150

The command line to launch qemu-kvm for winxp is:
sudo /home/user/local_install/bin/qemu-system-x86_64 -cpu core2duo -m 1024 -smp 2 -usb -vga std -hda ./winxpsp3.qcow -vnc :0 -boot c -usbdevice tablet -usbdevice host:0781:5150

Any help is appreciated.

Revision history for this message
Mirco Bauer (meebey) wrote :

I suffer from the same issue using QEMU 1.1. I tried 5 different USB thumbdrives and none of them worked. Interesting was that a USB 1.1 mouse was working though.

Revision history for this message
Carlos-velasco (carlos-velasco) wrote :

Same problem here, using:
qemu-kvm 0.13
kernel 2.6.36.2
kvm-intel

Guest:
Windows 7 Enterprise x64

INFO USBHOST:
  Device 2.2, speed 480 Mb/s
    Class 00: USB device 054c:02a5, Storage Media

INFO USB:
Device 0.3, Speed 480 Mb/s, Product Storage Media

Device appears in Windows 7 but in Error Code 10.

Revision history for this message
Carlos-velasco (carlos-velasco) wrote :

Ugh... I have just realized that KVM only supports UHCI, so not USB 2.0 support

Revision history for this message
sydenis (sydenis) wrote :

two years passed... nothihg changed....
qemu 0.14.1+win7(32/64) the problem persist

Wessel Dankers (wsl)
Changed in qemu:
status: New → Confirmed
Revision history for this message
Steve Rencontre (q-launchpad-q) wrote :

Just found this problem with Win7 guest, both 32 and 64-bit, using qemu-kvm 1.01. WinXP is absolutely fine.

How can this /possibly/ not be a priority to fix?

Revision history for this message
Daniël van Eeden (dveeden) wrote :

This is an issue for me with Win7 SP1 64-bit guest on Ubuntu 12.10 (qemu-kvm 1.2.0+noroms)

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

Waiting on a microsoft license, hoping to be able to test this in the next 2 weeks.

Changed in qemu-kvm (Ubuntu):
status: New → Confirmed
Revision history for this message
Sam Stoelinga (sammiestoel) wrote :

This is also affecting Windows Server 2008 and happens with all usb storage devices I tested.

Revision history for this message
Wessel Dankers (wsl) wrote :

Bug #1033727 is specifically about qemu-kvm 1.2.0 and higher, see comment #8 on that bug for example. This bug is about earlier versions, including the version in 12.04 LTS.

Revision history for this message
Sam Stoelinga (sammiestoel) wrote :

This maybe not a duplicate as we're using 1.3.1 and Windows 7 isn't working there either. All other Operating systems are working though.

@Wessel: I believe the bug you pointed out as duplicate is saying that USB passthrough isnt working on any guest OS, but this bug is specifically targeted about Windows 7 not working.

Revision history for this message
Wessel Dankers (wsl) wrote :

I don't recall saying there was a duplicate of this bug? I merely objected to #1033727 being marked a duplicate.

Revision history for this message
Sam Stoelinga (sammiestoel) wrote :

Lol weird it's not marked as duplicate anymore anyway, guess it was not you then. Don't know what happened.

Can this bug be fixed in KVM or is it really to Windows specific? Else I may have a look at it, never did any KVM development though, should be fun.

@Serge: Did you get the license already and had a look at this bug?

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

@Sam,

I have the license now, but haven't had a chance to reproduce yet, sorry. It's on my list.

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

Upstream git head still gives me this problem, as does back to 0.14.0.

Note however that the same qemu builds, with the same usb stick, work fine using a linux guest.

The same stick, inserted to the same windows version on native hardware also works.

So it's not bad hardware, it's not hardware unsupported by windows, and qemu *is* passing the usb device through sufficiently that windows SHOULD be able to make use of it.

So this appears to be something specific that windows wants.

I've seen mention of windows registry tricks involving removal of top and bottom filters for the device... I haven't tested that to see if that would be a workaround.

Revision history for this message
Jens Frederich (jfrederich) wrote :

Is there any workaround?

We're currently evaluating different RTOS systems. One is Linux RT with KVM/QEMU with Windows 7. This bug breaks the latency measurement setup and Linux RT is out of race. It there anyway to fix the issue?

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

Hi Jens,

could you tell us exactly what you are trying to pass through, what commands you've tried, and with what version of qemu (and, if hand-built, which options were passed to configure).

1.5 came with a new passthrough implementation, but alongside the old. So I wonder whether choosing the libusb based implementation would help.

Revision history for this message
Jens Frederich (jfrederich) wrote :
Download full text (3.1 KiB)

Hi Serge,

for your information. I sent a mail to the devel mailing list. See below.

I've tried to passthrough special Vector automotive usb in house devices.
Look here: http://vector.com/vi_vn1600_en.html.

What do you mean with "what commands you've tried"?

I've tried three QEMU versions:

1. Ubuntu 13.04 64-bit prebuild qemu-kvm package (qemu 1.4.0)
2. Ubuntu 13.10 64-bit prebuild qemu-kvm package (qemu 1.5.0)
3. Hand builded QEMU 1.6.1 with standard configure call
    $ ./configure --prefix=/opt/kvm && make -j

Next, I want to build qemu from git?

I use virt-manager or virsh to start/stop my guest. The QEMU command line is:

qemu-system-x86_64 -machine accel=kvm:tcg -name VRTP1_win -S -M pc-
i440fx-1.4 -cpu SandyBridge -m 3072 -smp 2,sockets=1,cores=2,threads=1
-uuid 8ee5add7-f1a9-d697-9c18-2c1b4967c00e -no-user-config -nodefaults
-chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/VRTP1_win.monitor,server,nowait
-mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime
-no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2
-device ahci,id=ahci0,bus=pci.0,addr=0x6 -drive
file=/var/lib/libvirt/images/VN8912_Development_0.9.2.bin,if=none,id
=drive-sata0-0-0,format=raw -device ide-hd,bus=ahci0.0,drive=drive-
sata0-0-0,id=sata0-0-0,bootindex=1 -netdev
tap,fd=27,id=hostnet0,vhost=on,vhostfd=28 -device virtio-net-
pci,netdev=hostnet0,id=net0,mac=52:54:00:71:f5:45,bus=pci.0,addr=0x3
-chardev pty,id=charserial0 -device isa-
serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc
127.0.0.1:0 -vga std -device intel-hda,id=sound0,bus=pci.0,addr=0x4
-device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device usb-
host,hostbus=3,hostaddr=18,id=hostdev0 -device virtio-balloon-
pci,id=balloon0,bus=pci.0,addr=0x5

Mail to devel list:

Hi all,

we're currently evaluating different RTOS systems (Windows CE, Intime, RTX, etc.).
One system is Linux RT + KVM/QEMU with a Windows 7 guest. Up to now all
works fine, Linux RT has good latency and KVM/Qemu setup was easy. But one QEMU bug
breaks my measurement setup and evaluation.

I've some usb devices for the Windows 7 guest. I configure them as USB passthrough.
The devices appears in the device manager of Windows 7, but with
"Error code 10": device cannot start". The Windows driver fails on USB set configuration.
The driver creates a IRP and send it via IOCTRL to lower layer. The IOCTRL fails with
invalid parameter.

driver log:
00000009 0.65470564 vnCDrvUsbControlRequestSetConfiguration, WdfUsbTargetDeviceSelectConfig single interface failed 0xc000000d
00000010 0.65472370 vnCDrvUsbIFPrepareHardwareState, vnCDrvUsbControlRequestSetConfiguration failed: 0xc000000d
00000011 0.65473646 vnCDrvDevConPrepareHardware, vnCDrvUsbIFPrepareHardwareState failed 0xc000000d
00000012 0.65474838 vnCDrvEvtDevicePrepareHardware, vnCDrvDevConPrepareHardware failed 0xc0000001
00000013 0.6547

This bug breaks my latency measurement setup and Linux RT is out of the evaluationg
race. Windows CE should not win :-), it there anyway workaround or hack to fix the issue?

My setup:

Ubuntu 64-bit
Windows 7 Embedded Guest
Linux Kernel: 3.10.10-rt7
QEMU: 1.4.0, 1.6.1

thanks...

Read more...

Revision history for this message
Jens Frederich (jfrederich) wrote :

All devices work on other hypervisors like VMware Workstation etc...

Revision history for this message
debfreak (tr-man) wrote :

I have the same problem. I tried it with qemu 1.4 and the last 1.6.0-dfsg-2 on a debian testing system. Win 7 says always "This device cannot start. (Code 10)". I tried a lot of usb sticks but always the same...
I hope there will be sometime a solution for this :( I wait over a year in the hope that this will work.

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

@FanFan,

if you start such a vm and do 'ps -ef | grep kvm' should see the kvm command line which is working for you.

Revision history for this message
Gonglei (arei-gonglei) wrote :

I think you should appoint the usb bus which according to your usb type, such as:
-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2
 -device usb-ehci,id=usb1,bus=pci.0,addr=0x4
 -device usb-hub,id=hub0,bus=usb.0,port=2
 -device usb-tablet,id=input0,bus=usb.0,port=1
 -device usb-host,hostbus=2,hostport=2,id=hostdev0,bus=usb1.0

Revision history for this message
Manuel Baesler (v-launchpad-manuelbaesler) wrote :

Hi, I had the same problem. Tested a lot. My solution to passthrough usb devices to a windows 7 x64 guest:

parameter part:

-device usb-ehci,id=usb,bus=pci.0,addr=0x4 -device usb-host,vendorid=0x{},productid=0x{},id=hostdev0,bus=usb.0

I also tried the device
piix4-usb-uhci

instead of usb-ehci

piix4-usb-uhci caused the Code 10 error in the windows device manager.

lsusb will give you a list of plugged in usb devices. eg.

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

1d6b:0002
and
1d6b:0003

are vendorid:prouctid

replace {} with the ids and it should work. I tested it with

- ssd usb 3.0 drive
- retail usb seagate usb 2.0 hdd drive.

Revision history for this message
Manuel Baesler (v-launchpad-manuelbaesler) wrote :

followup:

my understanding is there are a bunch of usb interfaces:

uhci is usb 1.0
ehci is usb 2.0
xhci is usb 3.0

-device piix3-usb-uhci will create an usb 1.0 interface. I guess usb 1.0 is insufficent for modern usb devices so windows errors with code 10. ehci have enough to bring full support for modern usb devices.

qemu is like LEGO where you can wire it all together :-)

refference:
https://github.com/qemu/qemu/blob/master/docs/usb2.txt
https://en.wikipedia.org/wiki/Host_controller_interface_(USB,_Firewire)#USB

Revision history for this message
Serge Hallyn (serge-hallyn) wrote : Re: [Bug 685096] Re: USB Passthrough not working for Windows 7 guest

Quoting Manuel Baesler (<email address hidden>):
> followup:
>
> my understanding is there are a bunch of usb interfaces:
>
> uhci is usb 1.0
> ehci is usb 2.0
> xhci is usb 3.0
> …
>
> -device piix3-usb-uhci will create an usb 1.0 interface. I guess usb 1.0
> is insufficent for modern usb devices so windows errors with code 10.
> ehci have enough to bring full support for modern usb devices.
>
> qemu is like LEGO where you can wire it all together :-)
>
> refference:
> https://github.com/qemu/qemu/blob/master/docs/usb2.txt
> https://en.wikipedia.org/wiki/Host_controller_interface_(USB,_Firewire)#USB

Thanks - so (this isn't documented in the qemu man page) am I to assume
that given " -usbdevice host:0781:5150" as the original bug submitter is
doing means "give me usb 1.0" ?

Max, does it work for you if you use (...taking a wild guess) :

 -device usb-ehci,id=usb,bus=pci.0,addr=0x4 \
 -device usb-host,vendorid=0x0781,productid=0x5150,id=hostdev0,bus=usb.0

or perhaps

 -device usb-ehci,id=usb,bus=pci.0,addr=0x4 \
 -usbdevice tablet \
 -device usb-host,vendorid=0x0781,productid=0x5150,id=hostdev0,bus=usb.0

You also might try xhci in place of ehci.

(If this does turn out to be the answer, then the bug title should be
changed to include 'usb2.0 and usb3.0 devices', to aid people in
finding this gem in the future)

 status: incomplete

Changed in qemu-kvm (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Manuel Baesler (v-launchpad-manuelbaesler) wrote :

RIght, with '-usb' qemu creates then 'piix3-usb-uhci' device:

00:01.2 USB controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev 01)

Revision history for this message
Michal Suchanek (hramrach) wrote :

I can connect to network with qemu 2.0 with and win 7 pro 64bit guest.

qemu-system-x86_64 -machine accel=kvm -smp 2 -m 1024 -net none -device usb-ehci,id=usb,bus=pci.0,addr=0x4 -device usb-host,vendorid=0x0b95,productid=0x772b,id=hostdev0,bus=usb.0 -usb -usbdevice tablet -hda /srv/rhev/virtual.qcow -soundhw hda -boot c

Bus 007 Device 014: ID 0b95:772b ASIX Electronics Corp.

Unfortunately there is lack of automation and documentation. Ideally you would use something like
qemu-system-x86_64 -machine accel=kvm -smp 2 -m 1024 -net none -usb2 -usbdevice host:0b95:772b -usbdevice tablet -hda /srv/rhev/virtual.qcow -soundhw hda -boot c

Tthe usb device info from Linux should be enough to determine if the device is to be connected to usb1 or usb2, right?

Revision history for this message
Michal Suchanek (hramrach) wrote :

So the RightWay(tm) to fix this is to download http://git.qemu.org/?p=qemu.git;a=blob_plain;f=docs/ich9-ehci-uhci.cfg;hb=HEAD

and run

qemu-system-x86_64 -net none -readconfig ich9-ehci-uhci.cfg -device usb-host,vendorid=0x0b95,productid=0x772b -device usb-tablet <extra options here>

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

Thanks Michal,

so at sounds like at least that file should be distributed with the qemu package. I don't know the best place for that, or how cleanly we can integrate it to make it easiest on the end-user...

Revision history for this message
Michal Suchanek (hramrach) wrote :

Actually, in qemu 2.0.0 the file is packaged. However, it is packaged in the qemu package rather than qemu-system package so users are unlikely to have the file.

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

The file seems to be in qemu-system-common (at least in Ubuntu 14.10).

The next question is how to best help the user to run the right command. Should it go into the manpage?

affects: qemu-kvm (Ubuntu) → qemu (Ubuntu)
Changed in qemu (Ubuntu):
importance: Undecided → Medium
status: Incomplete → Confirmed
Changed in qemu (Ubuntu):
importance: Medium → Low
Revision history for this message
Nehal J Wani (nehaljwani) wrote :

Comment No. 23 by Manuel Baesler worked for me in Windows 10.
lsusb gave me:
Bus 001 Device 040: ID 8564:1000 Transcend Information, Inc. JetFlash
Qemu Flags used:
-device usb-ehci,id=usb,bus=pci.0,addr=0x4 -device usb-host,vendorid=0x8564,productid=0x1000,id=hostdev0,bus=usb.0

Revision history for this message
FFO (fifo++) wrote :

The only way to see my iPhone (or any USB device) in the Windows guest is to have it redirected via "Spice", not with libvirt xml capture elements.

Select Redirect USB device in virt-viewer and it just works.

I have upgraded to Qemu 2.4, libvirt 1.2.21 and upgraded the qemu machine to "q35" as I tried hard to make it work via xml.
Now that I have it working, I don't plan to check if it works with less current software / machines.

Revision history for this message
Thomas Huth (th-huth) wrote :

If I get the previous comments right, this is just about using the right configuration, and not a real bug? If so, I assume we can close this ticket nowadays?

Changed in qemu:
status: Confirmed → Incomplete
Revision history for this message
Thomas Huth (th-huth) wrote :

Closing this bug for QEMU, since there haven't been any replies within the last 7 months.

Changed in qemu:
status: Incomplete → Won't Fix
Revision history for this message
Andreas Hasenack (ahasenack) wrote :

Also marking the ubuntu task as incomplete. It looks like it's sorted, but let's give it some time for people to comment if they still have an issue.

Changed in qemu (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Andreas Hasenack (ahasenack) wrote :

Doing the same for the debian task, which doesn't have an upstream bug anyway.

Changed in qemu (Debian):
status: New → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for qemu (Ubuntu) because there has been no activity for 60 days.]

Changed in qemu (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.