RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1179045 - [rfe] qemu should report usb-host hotplug errors
Summary: [rfe] qemu should report usb-host hotplug errors
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.1
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Gerd Hoffmann
QA Contact: hachen
URL:
Whiteboard:
: 1163046 1354197 (view as bug list)
Depends On:
Blocks: 1163048 1179992 1217326
TreeView+ depends on / blocked
 
Reported: 2015-01-06 02:03 UTC by Sibiao Luo
Modified: 2018-02-13 07:41 UTC (History)
18 users (show)

Fixed In Version: qemu 2.7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1179992 (view as bug list)
Environment:
Last Closed: 2017-08-01 23:27:12 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2017:2392 0 normal SHIPPED_LIVE Important: qemu-kvm-rhev security, bug fix, and enhancement update 2017-08-01 20:04:36 UTC

Description Sibiao Luo 2015-01-06 02:03:09 UTC 
Description of problem:
insert a usb stick in host, then pass-through the same host usb stick twice, VM can be boot up with 'libusbx: error' and guest only detect one usb stick. 

Version-Release number of selected component (if applicable):
host info:
# uname -r && rpm -q qemu-kvm-rhev
3.10.0-220.el7.x86_64
qemu-kvm-rhev-2.1.2-17.el7.x86_64
guest info:
3.10.0-220.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1.insert a 3.0 usb stick in host.
# lsusb | grep CompUSA
Bus 001 Device 003: ID 1516:6221 CompUSA 

2.pass-through the same host usb stick twice.
e.g:...-device nec-usb-xhci,id=xhci -device usb-host,hostbus=001,hostaddr=003,id=hostdev0,bus=xhci.0 -device usb-host,hostbus=001,hostaddr=003,id=hostdev1,bus=xhci.0

3.check the stick in monitor and guest.
# fdisk -l/ ls -lh /dev/sd*

Actual results:
after step 2, 
QEMU 2.1.2 monitor - type 'help' for more information
(qemu) c
(qemu) libusb_detach_kernel_driver: -5 [NOT_FOUND]
main_channel_link: add main channel client
main_channel_handle_parsed: net test: latency 1.657000 ms, bitrate 11377777777 bps (10850.694444 Mbps)
inputs_connect: inputs channel client create
red_dispatcher_set_cursor_peer: 
libusb_set_configuration: -6 [BUSY]
libusbx: error [submit_control_transfer] submiturb failed error -1 errno=16
libusbx: error [submit_bulk_transfer] submiturb failed error -1 errno=16
libusbx: error [op_release_interface] release interface failed, error -1 errno 22

(qemu) info status 
VM status: running
(qemu) info usb
  Device 0.2, Port 1, Speed 12 Mb/s, Product QEMU USB Tablet
  Device 1.1, Port 1, Speed 480 Mb/s, Product 
  Device 1.2, Port 2, Speed 480 Mb/s, Product 
(qemu) info usbhost 
  Bus 1, Addr 3, Port 6, Speed 480 Mb/s
    Class 00: USB device 1516:6221, 
  Bus 4, Addr 3, Port 1.1, Speed 1.5 Mb/s
    Class 00: USB device 0557:2213, CS-1734A V4.2.414
(qemu) 

after step 3, only detect the one usb stick in guest.
# ls /dev/sd* -lh
brw-rw----. 1 root disk 8, 0 Jan  6  2015 /dev/sda

Expected results:
it should no any error in monitor and work well or qemu should reject pass-through the same host usb stick twice.

Additional info:
Comment 1 Sibiao Luo 2015-01-06 02:06:22 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
Comment 2 Gerd Hoffmann 2015-01-06 08:10:11 UTC 
> 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.
Comment 6 Gerd Hoffmann 2016-06-13 11:44:15 UTC 
  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.
Comment 7 Gerd Hoffmann 2016-06-13 12:53:49 UTC 
*** Bug 1163046 has been marked as a duplicate of this bug. ***
Comment 8 Gerd Hoffmann 2016-08-01 11:07:11 UTC 
> 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.
Comment 9 Gerd Hoffmann 2016-08-01 11:08:17 UTC 
upstream commit is e058fa2dd599ccc780d334558be9c1d155222b80
Comment 10 David Gibson 2016-08-01 23:49:19 UTC 
*** Bug 1354197 has been marked as a duplicate of this bug. ***
Comment 13 Gerd Hoffmann 2017-01-18 08:16:48 UTC 
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.
Comment 14 hachen 2017-01-22 03:06:19 UTC 
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"
Comment 15 hachen 2017-01-22 03:18:37 UTC 
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.
Comment 20 errata-xmlrpc 2017-08-01 23:27:12 UTC 
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
Comment 21 errata-xmlrpc 2017-08-02 01:04:50 UTC 
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
Comment 22 errata-xmlrpc 2017-08-02 01:56:50 UTC 
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
Comment 23 errata-xmlrpc 2017-08-02 02:37:35 UTC 
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
Comment 24 errata-xmlrpc 2017-08-02 03:02:18 UTC 
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
Comment 25 errata-xmlrpc 2017-08-02 03:22:27 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.