Hi, hachen

   Please help to reproduce the bug and handle the "qa_ack" tag.


Thanks,
aliang

Another try with Win10

client/host:
usbredir-0.7.1-2.el7.x86_64
spice-server-0.12.8-2.el7.x86_64
qemu-img-rhev-2.8.0-6.el7.x86_64
kernel-3.10.0-657.el7.x86_64

Guest Win10 with RHEV-Toools 4.1-5:
/usr/libexec/qemu-kvm -name guest=win10,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu
/domain-3-win10/master-key.aes -machine pc-i440fx-rhel7.4.0,accel=kvm,usb=off,dump-guest-core=off -cpu Broadwell,+rtm,+hle,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 4096 -realtime mlock=off -smp 2,socke
ts=2,cores=1,threads=1 -uuid d47d10b5-1a6e-4590-be41-d01a44390b26 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-3-win10/monitor.sock,server,nowait -mon chardev=char
monitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device 
nec-usb-xhci,id=usb,bus=pci.0,addr=0x5 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/home/rduda/Virtualky/Windows-10-20170428.0-x86_64.qcow2,format=qcow2,if=none,id=drive-ide0-0-0 -
device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive file=/home/rduda/Virtualky/RHEV-toolsSetup_4.1_5.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on -device ide-cd,bus=ide.0,u
nit=1,drive=drive-ide0-0-1,id=ide0-0-1 -netdev tap,fd=26,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:ec:9e:24,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charse
rial0,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,po
rt=1 -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=p
ci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bu
s=usb.0,port=2 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -msg timestamp=on

USB3 in host/client:

lsusb -t (excerpt)
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
    |__ Port 1: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
    |__ Port 3: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M


I connected to guest with remote-viewer and redirected USB 3. Device is redirected, but the content cannot be displayed. See attached screenshot.

dmesg:
[ 9366.879190] usb 3-1: reset SuperSpeed USB device number 5 using xhci_hcd
[ 9387.302223] usb 3-1: reset SuperSpeed USB device number 5 using xhci_hcd
[ 9408.386225] usb 3-1: reset SuperSpeed USB device number 5 using xhci_hcd
[ 9429.489230] usb 3-1: reset SuperSpeed USB device number 5 using xhci_hcd
[ 9450.584255] usb 3-1: reset SuperSpeed USB device number 5 using xhci_hcd
[ 9471.692285] usb 3-1: reset SuperSpeed USB device number 5 using xhci_hcd
[ 9492.834279] usb 3-1: reset SuperSpeed USB device number 5 using xhci_hcd
[ 9513.942841] usb 3-1: reset SuperSpeed USB device number 5 using xhci_hcd
[ 9535.161297] usb 3-1: reset SuperSpeed USB device number 5 using xhci_hcd

Created attachment 1274862 [details]
Trying to display files on USB3 stick in Win10 guest

Created attachment 1274864 [details]
spice-debug log while redirecting and loading USB3 drive in guest

Just for information: USB3.0 disk redirection worked without problem in following setup:
host: fedora 25, qemu-kvm 2.7.1-4, spice server 3.13
guest: win10 with nec-xhci
client: win10 + UsbDk 0.19 + spice client 5.0-256
disk: SanDisk Extreme USB 3.0
Worked when the disk is connected to usb3 hub on client and when connected to usb2 hub on client. Also usb redirection from host usb3 connector works without problems.

I had a go with:
host:
qemu-kvm-rhev-2.9.0-2.el7.x86_64
kernel-3.10.0-656.el7.x86_64
guest:
win2016

1. Start the guest through qemu cmd:
 /usr/libexec/qemu-kvm \
    -name 'avocado-vt-vm1'  \
    -sandbox off  \
    -machine pc  \
    -nodefaults  \
    -vga std  \
    -device pvpanic,ioport=0x505,id=id4FzGzg  \
    -device nec-usb-xhci,id=controller,bus=pci.0,addr=0x7 \
    -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.0,addr=0x3 \
    -drive id=drive_image1,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/home/kvm_autotest_root/images/win2016-64-virtio-scsi.qcow2 \
    -device scsi-hd,id=image1,drive=drive_image1 \
    -device virtio-net-pci,mac=9a:4e:4f:50:51:52,id=idH8iBKj,vectors=4,netdev=iduyb7Wr,bus=pci.0,addr=0x4  \
    -netdev tap,id=iduyb7Wr \
    -m 8192  \
    -smp 4,cores=2,threads=1,sockets=2  \
    -cpu 'SandyBridge',+kvm_pv_unhalt,hv_spinlocks=0x1fff,hv_vapic,hv_time \
    -drive id=drive_cd1,if=none,snapshot=off,aio=native,cache=none,media=cdrom,file=/home/kvm_autotest_root/iso/windows/winutils.iso \
    -device scsi-cd,id=cd1,drive=drive_cd1 \
    -device usb-tablet,id=usb-tablet1,bus=controller.0,port=1  \
    -vnc :0  \
    -rtc base=localtime,clock=host,driftfix=slew  \
    -boot order=cdn,once=c,menu=off,strict=off \
    -enable-kvm \
    -monitor stdio \
    -qmp tcp:localhost:4444,server,nowait \
    -spice port=5931,disable-ticketing \
    -chardev spicevmc,name=usbredir,id=usbredirchardev1 \
    -device usb-redir,id=redir1,chardev=usbredirchardev1,bus=controller.0\

2. Connect the host
# remote-viewer spice://host_ip:5931

3. After win2016 guest, redirect the usb 3.0 device, and open win CMD:
C:\Users\Administrator> diskpart

DISKPART> list disk
The redirected USB 3.0 device was displayed.

Through both Disk Management and 'This PC', it can be checked.Pls check the attached.

The result is same for usb 2.0 flash drive.

Created attachment 1277788 [details]
usb 3.0 flash dirve can be found

You should be able to see the usb device through 'list disk' without doing anything.

However, you may need to format your usb flash dirve in order to have it displayed in 'This PC'

I can reproduce the issue with Radek's flash drive and have traced it down to this constant in hw/usb/hcd-xhci.c:

#define TRB_LINK_LIMIT  4

used in xhci_ring_fetch and xhci_ring_chain_length.

The first ~30 mass storage commands issued by Windows fit within the limit which is why the drive is recognized by Windows and appears in This PC. But then a 512 kiB bulk read comes in with 5 TRBs of type TR_LINK which is rejected by the QEMU xhci implementation and the communication stalls.

I'll read up some more on xhci to see if we can just increase the limit.

we had that with ohci too (see ab6b1105a2259c7072905887f71caa850ce63190).
just raising is fine.

(In reply to Gerd Hoffmann from comment #13)
> we had that with ohci too (see ab6b1105a2259c7072905887f71caa850ce63190).
> just raising is fine.

Thanks! Patch posted.

https://lists.nongnu.org/archive/html/qemu-devel/2017-05/msg03048.html

*** Bug 1450285 has been marked as a duplicate of this bug. ***

Fix included in qemu-kvm-rhev-2.9.0-6.el7

Based on the comment 17, I test on the same machine and .qcow2 :
kernel-3.10.0-656.el7.x86_64
qemu-kvm-rhev-2.9.0-6.el7.x86_64

The Win2016 guest can boot up. The usb disk is accessible.
Bug verified.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:2392