usb-uas does not work in Windows (10) guest

[Tom Yan]

When I attach a "-device usb-uas" to a VM with Windows 10 10586, the device fail to start with the following error in the guest:

"The device cannot start. (Code 10)

{Operation Failed}
The requested operation was unsuccessful"

If the host controller is nec-usb-xhci, there will be two of the following error on the terminal of the host as well:

"qemu-system-x86_64: usb_uas_handle_control: unhandled control request"

If it's usb-ehci, ich9-usb-ehci1 or ich9-usb-echi2, this will not show up on the host side, but the device stil fails with the same error on the guest side.

[Tom Yan (tom-ty89)]

usb-bot works fine

[Tom Yan (tom-ty89)]

Also tried to "passthrough" the SCSI layer of an actual UASP drive with scsi-block. No luck either.

[Tom Yan (tom-ty89)]

Not sure if it's relevant, but when I try completely passthrough a UASP device to the VM through usb-host, only the BOT/MSC part is exposed. This is not the case when I do the same thing to a Linux guest (btw usb-uas apparently works fine in Linux guest as well).

[Tom Yan (tom-ty89)]

I am using qemu-2.5.1. Here are the commands I used in the test cases:

qemu-system-x86_64 -enable-kvm -cpu host -m 2G -net none -full-screen -drive file=disks/uas.qcow2,format=qcow2,cache=none,aio=native -drive file=test.img,format=raw,if=none,id=test -device nec-usb-xhci -device usb-uas -device scsi-hd,drive=test

qemu-system-x86_64 -enable-kvm -cpu host -m 2G -net none -full-screen -drive file=disks/uas.qcow2,format=qcow2,cache=none,aio=native -drive file=test.img,format=raw,if=none,id=test -device nec-usb-xhci -device usb-bot -device scsi-hd,drive=test

qemu-system-x86_64 -enable-kvm -cpu host -m 2G -net none -full-screen -drive file=disks/uas.qcow2,format=qcow2,cache=none,aio=native -drive file=/dev/sdc,format=raw,if=none,id=test -device nec-usb-xhci -device usb-uas -device scsi-block,drive=test

qemu-system-x86_64 -enable-kvm -cpu host -m 2G -net none -full-screen -drive file=disks/uas.qcow2,format=qcow2,cache=none,aio=native -device nec-usb-xhci -device usb-host,hostbus=2,hostport=6

[Tom Yan (tom-ty89)]

Also tried to "passthrough" the SCSI layer of an actual UASP drive with scsi-block. No luck either.

[Tom Yan (tom-ty89)]

Not sure if it's relevant, but when I try completely passthrough a UASP device to the VM through usb-host, only the BOT/MSC part is exposed. This is not the case when I do the same thing to a Linux guest (btw usb-uas apparently works fine in Linux guest as well).

[Ashish Girdhar (ashishgirdhar)]

I am also facing this issue.

On further probing, I found out that usb-uas in Qemu doesn't support "SET_SEL" control command due to which windows driver "uaspstor.sys" couldn't complete the enumeration.

It is clearly mentioned in USB 3.1 specs that uasp devices should handle two new control commands - SET_SEL and SET_ISOCH_DELAY.

[Jack Coulter (jscinoz)]

Just echoing Tom Yan's comment; I've tried passing through what appears to be the very same device (if not, at least the same UAS-SATA bridge) to a VM in its entirety.

I can confirm the same result - with an otherwise identical domain configuration, Linux guests correctly use the UAS driver:

/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
    |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M

Whereas Windows guests fall back to BOT/MSC:

<see attached image>

In both cases, QEMU is being run via libvirt, which is generating the following command line:

/usr/bin/qemu-system-x86_64 -name guest=Win10-Edge-IE11,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-13-Win10-Edge-IE11/master-key.aes -machine pc-q35-2.7,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu host,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 4096 -realtime mlock=off -smp 8,sockets=1,cores=4,threads=2 -uuid 47c39707-088c-4edc-8b6a-a7856e09f43d -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-13-Win10-Edge-IE11/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 -boot strict=on -device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1e -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x0 -device nec-usb-xhci,id=usb,bus=pci.2,addr=0x6 -device virtio-scsi-pci,id=scsi0,bus=pci.2,addr=0x3 -device virtio-serial-pci,id=virtio-serial0,bus=pci.2,addr=0x4 -drive file=/home/jack/IMG/Win10-Edge-IE11.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0,discard=unmap -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -drive if=none,id=drive-scsi0-0-0-1,readonly=on -device scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1 -netdev tap,fd=22,id=hostnet0,vhost=on,vhostfd=24 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:27:94:5d,bus=pci.2,addr=0x1 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0,bus=usb.0,port=2 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1 -device intel-hda,id=sound0,bus=pci.2,addr=0x2 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=3 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=4 -device usb-host,hostbus=4,hostaddr=4,id=hostdev0,bus=usb.0,port=1 -device virtio-balloon-pci,id=balloon0,bus=pci.2,addr=0x5 -msg timestamp=on

[Tom Yan (tom-ty89)]

I think they are two separate issues in usb-uas and usb-host respectively. I probably should not have bring in the usb-host case here but create another report for it.

[Jack Coulter (jscinoz)]

Noted, I've created https://bugs.launchpad.net/qemu/+bug/1648726 to track the issue with passing through physical UAS devices.

[Thomas Huth (th-huth)]

The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.

[Launchpad Janitor (janitor)]

[Expired for QEMU because there has been no activity for 60 days.]