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

Bug #1579306 reported by Tom Yan on 2016-05-07
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
QEMU
Undecided
Unassigned

Bug Description

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) wrote :
Tom Yan (tom-ty89) wrote :

usb-bot works fine

Tom Yan (tom-ty89) wrote :

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

Tom Yan (tom-ty89) wrote :

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) wrote :

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) wrote :

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

Tom Yan (tom-ty89) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers