Bug 1179045
Summary: | [rfe] qemu should report usb-host hotplug errors | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Sibiao Luo <sluo> | |
Component: | qemu-kvm-rhev | Assignee: | Gerd Hoffmann <kraxel> | |
Status: | CLOSED ERRATA | QA Contact: | hachen <hachen> | |
Severity: | medium | Docs Contact: | ||
Priority: | medium | |||
Version: | 7.1 | CC: | chayang, cliao, coli, hachen, hdegoede, juli, juzhang, knoel, kraxel, mdeng, michen, mrezanin, ngu, qzhang, rbalakri, virt-maint, xfu, xuma | |
Target Milestone: | rc | Keywords: | FutureFeature | |
Target Release: | --- | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | qemu 2.7 | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 1179992 (view as bug list) | Environment: | ||
Last Closed: | 2017-08-01 23:27:12 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 1163048, 1179992, 1217326 |
Description
Sibiao Luo
2015-01-06 02:03:09 UTC
BTW, if i use the remore passthrough(usb redirect) and local passthrough the same usb stick, the remote-viewer will give a waring that USB redirection error: Could not redirect CompUSA Device: Device is in use by another application, but the qemu monitor is ok. e.g:...-device nec-usb-xhci,id=xhci -chardev spicevmc,name=usbredir,id=usbredirchardev1 -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,bus=xhci.0,port=1,debug=3 -device usb-host,hostbus=001,hostaddr=003,id=hostdev0,bus=xhci.0 Best Regards, sluo > Expected results:
> it should no any error in monitor and work well or qemu should reject
> pass-through the same host usb stick twice.
Reject pass-though isn't going to work as attaching usb devices is done asynchronously. Reasonable approach could be to send qmp events on usb-host attach/detach/error (there is a simliar bug somewhere else), so the failure can be signaled to the user instead of just showing up in the stderr log.
Needs to be solved upstream first, so 7.1 isn't going to fly, deadline way too close.
Hi, > Reject pass-though isn't going to work as attaching usb devices is done > asynchronously. Reasonable approach could be to send qmp events on usb-host > attach/detach/error (there is a simliar bug somewhere else), so the failure > can be signaled to the user instead of just showing up in the stderr log. Well, plan correction: async attach will continue to happen in case fixed properties (vendor/product id, physical port) are specified. In case the host address (which is not fixed will change each time the device is plugged in) is used to specify the device keep watching for the device isn't very useful though and qemu will likely switch behavior in 2.7 https://patchwork.ozlabs.org/patch/629734/ libvirt will exclusively use bus+address for assignment. libvirt can't leave the host usb bus monitoring to qemu anyway because device permissions and labels must be adjusted before qemu can actually access the device. So scratch the qmp events idea. qemu will start throwing errors instead. Only remaining question is whenever we'll just fix it upstream and pick it up with the 7.4 rebase or whenever we'll go backport this to 7.3. The change has the potential explore bugs in the libvirt usb assignment error handling code which never ran before ... kicked scratch build: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=11170690 Assigning to libvirt for comments. *** Bug 1163046 has been marked as a duplicate of this bug. *** > Only remaining question is whenever we'll just fix it upstream and pick it
> up with the 7.4 rebase or whenever we'll go backport this to 7.3. The
> change has the potential explore bugs in the libvirt usb assignment error
> handling code which never ran before ...
>
> kicked scratch build:
> https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=11170690
>
> Assigning to libvirt for comments.
No comment yet. 7.3 devel period is over, so we'll go with the 7.4 rebase. Updating bug accordingly.
upstream commit is e058fa2dd599ccc780d334558be9c1d155222b80 *** Bug 1354197 has been marked as a duplicate of this bug. *** As in the initial comment: try pass through a non-existing usb device using "-device usb-host,hostbus=<nr>,hostaddr=<nr>", qemu should throw an error now. host: 3.10.0-541.el7.x86_64 qemu-img-rhev-2.8.0-2.el7.x86_64 1. insert a usb into host [root@dhcp-8-164 ~]# 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 004: ID 0951:1642 Kingston Technology DT101 G2 <---- the usb Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub ... 2. on rhel74-64 guest,pass-through the same host usb stick twice /usr/libexec/qemu-kvm \ -name 'avocado-vt-vm1' \ -sandbox off \ -machine pc \ -nodefaults \ -vga cirrus \ -chardev socket,id=qmp_id_qmpmonitor1,path=/var/tmp/hachen/monitor-qmpmonitor1-20170120-180401-uWku8WbX,server,nowait \ -mon chardev=qmp_id_qmpmonitor1,mode=control \ -chardev socket,id=qmp_id_catch_monitor,path=/var/tmp/hachen/monitor-catch_monitor-20170120-180401-uWku8WbX,server,nowait \ -mon chardev=qmp_id_catch_monitor,mode=control \ -device pvpanic,ioport=0x505,id=idxoFmdx \ -chardev socket,id=serial_id_serial0,path=/var/tmp/hachen/serial-serial0-20170120-180401-uWku8WbX,server,nowait \ -device isa-serial,chardev=serial_id_serial0 \ -chardev socket,id=seabioslog_id_20170120-180401-uWku8WbX,path=/var/tmp/hachen/seabios-20170120-180401-uWku8WbX,server,nowait \ -device isa-debugcon,chardev=seabioslog_id_20170120-180401-uWku8WbX,iobase=0x402 \ -device ich9-usb-ehci1,id=usb1,addr=1d.7,multifunction=on,bus=pci.0 \ -device ich9-usb-uhci1,id=usb1.0,multifunction=on,masterbus=usb1.0,addr=1d.0,firstport=0,bus=pci.0 \ -device ich9-usb-uhci2,id=usb1.1,multifunction=on,masterbus=usb1.0,addr=1d.2,firstport=2,bus=pci.0 \ -device ich9-usb-uhci3,id=usb1.2,multifunction=on,masterbus=usb1.0,addr=1d.4,firstport=4,bus=pci.0 \ -drive id=drive_image1,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/home/kvm_autotest_root/images/rhel74-64-virtio.qcow2 \ -device virtio-blk-pci,id=image1,drive=drive_image1,bootindex=0,bus=pci.0,addr=03 \ -device virtio-net-pci,mac=9a:1d:1e:1f:20:21,id=idndA2FD,vectors=4,netdev=idRZl6iJ,bus=pci.0,addr=04 \ -netdev tap,id=idRZl6iJ \ -m 4096 \ -smp 4,maxcpus=4,cores=2,threads=1,sockets=2 \ -cpu 'SandyBridge',+kvm_pv_unhalt \ -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 \ -vnc :0 \ -rtc base=utc,clock=host,driftfix=slew \ -boot order=cdn,once=c,menu=off,strict=off \ -enable-kvm \ -monitor stdio \ -device nec-usb-xhci,id=xhci \ -device usb-host,hostbus=001,hostaddr=004,id=hostdev0,bus=xhci.0 \ <--once -device usb-host,hostbus=001,hostaddr=004,id=hostdev1,bus=xhci.0 \ <--twice 3.check the stick in monitor and guest. on host:(qemu) qemu-kvm: libusb_set_configuration: -6 [BUSY] (qemu) info usb Device 0.2, Port 1, Speed 480 Mb/s, Product QEMU USB Tablet, ID: usb-tablet1 Device 1.1, Port 1, Speed 480 Mb/s, Product DT 101 G2, ID: hostdev0 Device 1.1, Port 2, Speed 480 Mb/s, Product DT 101 G2, ID: hostdev1 it emulates two usbs, but it can not config those usbs correctly. guest can boot up. # dmesg | grep usb [ 1.961417] usb 5-2: new high-speed USB device number 2 using xhci_hcd [ 2.544748] usb 5-2: New USB device found, idVendor=0951, idProduct=1642 [ 2.545268] usb 5-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 2.545821] usb 5-2: Product: DT 101 G2 [ 2.546105] usb 5-2: Manufacturer: Kingston [ 2.546433] usb 5-2: SerialNumber: 001CC0EC32C7BB4107110077 [ 2.547155] usb 5-2: can't set config #1, error -32 <-- can not config it # lsusb Bus 005 Device 002: ID 0951:1642 Kingston Technology DT101 G2 <--one usb appears # fdisk -l you can not find the usb disk Base on this info, I don't think it is a bug. In addition, I have tried pass through a non-existing usb device, qemu throws an error: "qemu-kvm: -device usb-host,hostbus=001,hostaddr=006,id=hostdev1,bus=xhci.0: failed to find host usb device 1:6" About comment #14, what I was trying to say is, qemu rejects pass-through the same host usb stick twice, as it can not set configuration. Thus, I think it doesn't have this problem on 3.10.0-541.el7.x86_64 qemu-img-rhev-2.8.0-2.el7.x86_64. 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 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 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 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 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 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 |