Description of problem: Hotplug passthrough device induced error message from hmp Version-Release number of selected component (if applicable): kernel-3.10.0-510.el7.ppc64le qemu-kvm-rhev-2.6.0-27.el7.ppc64le SLOF-20160223-6.gitdbbfda4.el7.noarch RHEL7.3BE guest with kernel-3.10.0-510.el7.ppc64 How reproducible: 3/3 Steps to Reproduce: 1.boot up guest [root@ibm-p8-rhevm-06 home]# /usr/libexec/qemu-kvm -name avocado-vt-vm1 -sandbox off -machine pseries -nodefaults -vga std -device pci-ohci,id=usb0,bus=pci.0,addr=03 -device usb-kbd,id=input0,bus=usb0.0 -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.0,addr=04 -drive id=drive_image1,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=RHEL-Server-7.3-ppc64-virtio-scsi.qcow2 -device scsi-hd,id=image1,drive=drive_image1,bootindex=3 -device virtio-net-pci,mac=9a:09:0a:0b:0c:0d,id=idLLoQ97,vectors=4,netdev=hostnet0,bus=pci.0,addr=05,bootindex=2 -netdev tap,id=hostnet0,vhost=on,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown -m 4096 -smp 2,maxcpus=2,cores=1,threads=1,sockets=2 -device usb-ehci,id=ehci,bus=pci.0 -drive file=/home/storage.qcow2,if=none,id=drive-virtio-0-1,media=disk,format=qcow2,cache=none -device usb-storage,drive=drive-virtio-0-1,id=virt0-0-1,bus=ehci.0,bootindex=1 -vnc :0 -rtc base=utc,clock=host -boot order=cdn,once=d,menu=off,strict=off -enable-kvm -monitor unix:./monitor,server,nowait -qmp tcp:0:4444,server,nowait -boot menu=on -device usb-ehci,id=controller0 2.sh script for((i=1;i<=100;i++));do echo "device_add usb-host,id=usbhub$i,hostbus=1,hostaddr=2,bus=controller0.0" |nc -U monitor;echo "info usb" |nc -U monitor; sleep 2; echo "device_del usbhub$i" |nc -U monitor;echo "info usb" |nc -U monitor;sleep 2; done 3. Actual results: libusb: error [do_close] Device handle closed while transfer was still being processed, but the device is still connected as far as we know libusb: warning [do_close] A cancellation for an in-flight transfer hasn't completed but closing the device handle libusb: error [do_close] Device handle closed while transfer was still being processed, but the device is still connected as far as we know libusb: warning [do_close] A cancellation for an in-flight transfer hasn't completed but closing the device handle Expected results: guest work well without any error message. Additional info: QE will try it on x86 later.
It is a usb stick from host.
As well as trying on x86, can you try to narrow down the triggering conditions a bit: * Your example has 3 USB controllers. Does the problem still reproduce if you only have a single USB controller? * It appears you are performing the hotplug on an OHCI controller in the guest. Does the problem still reproduce with an EHCI or xHCI controller in the guest? * Does the error always occur on the first iteration of your test loop? Or does it sucessfully complete some iterations before failing?
QE took vacation from Oct 1 to Oct 9 because of Chinese National Day,anyway,I will give the answer as soon as possible.
(In reply to David Gibson from comment #3) > As well as trying on x86, can you try to narrow down the triggering > conditions a bit: > > * Your example has 3 USB controllers. Does the problem still reproduce if > you only have a single USB controller? It still can be reproduced with single usb device ...-device usb-ehci,id=controller0... > * It appears you are performing the hotplug on an OHCI controller in the > guest. Does the problem still reproduce with an EHCI or xHCI controller in > the guest? I used just "-device usb-ehci,id=controller0" and only by it that I can reproduce the bug.Others can't. > * Does the error always occur on the first iteration of your test loop? > Or does it sucessfully complete some iterations before failing? It won't happen at the first iteration but it will happen within 5 iterations.Besides,it will be reproduced on both rhel7.3 BE and LE guest. Any issues please let me know,thanks a lot.
It was't reproduced on x86 platform with ehci/xhci/ohci.
(In reply to dengmin from comment #6) > It was't reproduced on x86 platform with ehci/xhci/ohci. Correct it It was't reproduced on x86 platform with ehci/xhci/uhci.
dengmin, thanks for the extra information. This is too late for 7.3, moving to 7.4. Given that it's with one passthrough case on the EHCI controller, which is not the currently recommended one, I don't think 7.3.z is justified.
AFAIK, if the physical device is plugged into an XHCI controller slot on the host (which should be always the case on POWER8), you have to use an XHCI controller in the guest, too. EHCI won't work here (see also https://bugzilla.redhat.com/show_bug.cgi?id=1274588#c7 ). So unless I missed something, I'd say this is simply a configuration error here, not a real bug.
Gerd, Can you confirm if host HCI needs to match guest HCI for USB passthrough (see comment 9).
> Can you confirm if host HCI needs to match guest HCI for USB passthrough > (see comment 9). It's not that simple ... uhci supports usb1.1 ohci supports usb1.1 ehci supports usb2 ehci+companion controller (uhci or ohci) supports both usb1.1 and usb2 xhci supports usb1.1 and usb2 and usb3 Whenever things are working or not depends on what the usb device and the host usb controller support. Given the device in question is a usb stick, which typically supports either usb2 or both usb2 and usb3 (no usb1.1 unless they are *very* old): (1) A pure usb2 stick should have worked. (2) A usb2+usb3 stick plugged into a usb3 port on the host may not work with ehci, due to usb3 not being supported by ehci. (3) A usb2+usb3 stick plugged into a usb2 port on the host should work with ehci (b/c it'll run in usb2 mode). So, this issue could either be the case (2) incompatibility, or a endian bug somewhere in the ehci stack (could be both qemu emulation and linux guest driver). But, yes, the easiest answer to this is "just use xhci". xhci supports all usb versions and speeds and therefore all usb devices should just work, no matter how they are plugged in on the host machine. So no complicated compatibility rules, and xhci probably has also seen more testing than ehci (on ppc).
Thanks for the info, Gerd! Min Deng, could you find out whether the USB stick that you used here is USB2 or USB3 ?
(In reply to Thomas Huth from comment #12) > Thanks for the info, Gerd! > > Min Deng, > could you find out whether the USB stick that you used here is USB2 or USB3 ? Yes,I glad to tell you the exact USB stick but I need to contact eng-ops firstly because all the USB are managed by them remotely.
Still mark need info myself.
Min, If you grab the output of 'lsusb -vv' on the _host_ I think we can figure it out from there.
Created attachment 1228277 [details] USBofinfo
dengmin, It looks like the device is USB 2.0 (also it appears to be a memory card reader rather than a simple memory stick). So that suggests there is a real qemu bug. However, since there is little reason to use an ehci instead of an xhci in the guest, I'm not sure it's worth pursuing this in detail.
I've now tried to reproduce the problem, and I can also see it on my x86 laptop with RHEL 7.3. I've started QEMU like this: sudo /usr/libexec/qemu-kvm -nodefaults -hda rhel74-server.qcow2 -vga std \ -vnc :1 -m 4G -enable-kvm -monitor unix:./monitor,server,nowait \ -qmp tcp:0:4444,server,nowait -boot menu=on -device usb-ehci,id=controller0 And once the guest has been booted, I've run the device_add/device_del dance in another terminal: for((i=1;i<=100;i++));do \ echo "device_add usb-host,id=usbhub$i,hostbus=2,hostaddr=9,bus=controller0.0" \ |nc -U monitor;echo "info usb" |nc -U monitor; sleep 2; \ echo "device_del usbhub$i" |nc -U monitor;echo "info usb" |nc -U monitor; \ sleep 2; done The USB device at hostbus=2,hostaddr=9 is an USB stick, according to lsusb: Bus 002 Device 009: ID 0457:0151 Silicon Integrated Systems Corp. Super Flash 1GB / GXT 64MB Flash Drive As soon as the first device_del has been executed, I can see these messages in the terminal where I started QEMU: libusb: error [do_close] Device handle closed while transfer was still being processed, but the device is still connected as far as we know libusb: warning [do_close] A cancellation for an in-flight transfer hasn't completed but closing the device handle And FWIW, I'm using qemu-kvm-1.5.3-126.el7.x86_64 here, not qemu-kvm-rhev. Since this bug is also reproducible on x86, I'm setting Hardware=All now. And since the error messages come from libusb, I think the bug is rather there than in QEMU, so I'm setting the component to libusbx now for further investigation.
The do_close messages point to a problem with the application using libusbx, not a bug in libusbx itself, changing component to qemu-kvm.
Yep, qemu doesn't bother explicitly canceling in-flight requests on close. So hot-unplugging a busy device will make libusb complain (depending on the version, older versions didn't do this). It's purely cosmetical.
Also hit when unplug passthrough keyboard. Versions: Host: kernel-4.18.0-165.el8.x86_64 qemu-kvm-4.2.0-4.module+el8.2.0+5220+e82621dc Guest: kernel-4.18.0-159.el8.x86_64 Steps: 1. list usb device on host # lsusb Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 009: ID 17ef:6050 Lenovo Bus 001 Device 007: ID 03f0:0324 HP, Inc SK-2885 keyboard Bus 001 Device 005: ID 0951:1666 Kingston Technology DataTraveler 100 G3/G4/SE9 G2 Bus 001 Device 006: ID 04e6:5116 SCM Microsystems, Inc. SCR331-LC1 / SCR3310 SmartCard Reader Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub 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 Bus 003 Device 003: ID 0557:2213 ATEN International Co., Ltd CS682 2-Port USB 2.0 DVI KVM Switch Bus 003 Device 002: ID 0557:7000 ATEN International Co., Ltd Hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub 2. passthrough keyboard -device qemu-xhci,id=controller,bus=pci.7,addr=0x0 \ -device usb-host,hostbus=1,hostaddr=7,id=host-usbkbd,bus=controller.0 \ 3. usb info in hmp monitor # sh case-rhel7-42106-passthrough-mouse-keyboard-via-bus.sh QEMU 4.2.0 monitor - type 'help' for more information (qemu) info usb Device 0.1, Port 1, Speed 5000 Mb/s, Product QEMU USB MSD, ID: storage Device 1.2, Port 2, Speed 1.5 Mb/s, Product HP Basic USB Keyboard, ID: host-usbkbd 4. unplug keyboard via qmp {"execute":"qmp_capabilities"} {"return": {}} {"execute":"device_del","arguments":{"id":"host-usbkbd"}} {"timestamp": {"seconds": 1577786848, "microseconds": 420512}, "event": "DEVICE_DELETED", "data": {"device": "host-usbkbd", "path": "/machine/peripheral/host-usbkbd"}} {"return": {}} After step 4: unplug successfully via qmp monitor. But hit error message in hmp monitor, (qemu) libusb: error [do_close] Device handle closed while transfer was still being processed, but the device is still connected as far as we know libusb: warning [do_close] A cancellation for an in-flight transfer hasn't completed but closing the device handle (qemu) (qemu) info usb Device 0.1, Port 1, Speed 5000 Mb/s, Product QEMU USB MSD, ID: storage
QEMU has been recently split into sub-components and as a one-time operation to avoid breakage of tools, we are setting the QEMU sub-component of this BZ to "General". Please review and change the sub-component if necessary the next time you review this BZ. Thanks
*** Bug 1749745 has been marked as a duplicate of this bug. ***
upstream commit 76d0a9362c6a6a7d88aa18c84c4186c9107ecaef (qemu 5.0) rhel 8.3 rebase should pick this up.
Commit mentioned by Gerd is part of the current rebase. Moving to MODIFIED.
Hi Gerd, Reproduced with qemu-kvm-4.2.0-19.module+el8.3.0+6478+69f490bb: (qemu) libusb: error [do_close] Device handle closed while transfer was still being processed, but the device is still connected as far as we know libusb: warning [do_close] A cancellation for an in-flight transfer hasn't completed but closing the device handle qemu-kvm: warning: no device attached to queue qemu-kvm: warning: no device attached to queue qemu-kvm: warning: no device attached to queue libusb: error [do_close] Device handle closed while transfer was still being processed, but the device is still connected as far as we know libusb: warning [do_close] A cancellation for an in-flight transfer hasn't completed but closing the device handle qemu-kvm: warning: no device attached to queue libusb: error [do_close] Device handle closed while transfer was still being processed, but the device is still connected as far as we know Can't find error information with qemu-kvm-5.0.0-2.module+el8.3.0+7379+0505d6ca. But still have warnings in HMP: (qemu) qemu-kvm: warning: no device attached to queue qemu-kvm: warning: no device attached to queue qemu-kvm: warning: no device attached to queue qemu-kvm: warning: no device attached to queue qemu-kvm: warning: no device attached to queue qemu-kvm: warning: no device attached to queue qemu-kvm: warning: no device attached to queue qemu-kvm: warning: no device attached to queue qemu-kvm: warning: no device attached to queue Is this expected? Thanks, yduan
Yes, sort of. ehci_trace_guest_bug() prints the message. But given we have a tracepoint next to it which can be enabled if needed printing this warning is a bit pointless ... It is an unrelated issue though, so please open a separate bug for this.
Thanks Gerd, I filed a new bz [1] to track the pointless warning problem. Change to VERIFIED according to Comment 30 and Comment 31. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1859236
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 (virt:8.3 bug fix and enhancement update), 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/RHBA-2020:5137