Bug 1046612
| Summary: | qemu should quit with friendly prompt when use usb3.0 stick + uhci controller | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Sibiao Luo <sluo> | |
| Component: | qemu-kvm-rhev | Assignee: | Gerd Hoffmann <kraxel> | |
| Status: | CLOSED ERRATA | QA Contact: | Xujun Ma <xuma> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | medium | |||
| Version: | 7.0 | CC: | chayang, coli, hachen, hdegoede, hhuang, jinzhao, juzhang, knoel, kraxel, mdeng, michen, mrezanin, qzhang, rbalakri, sharpwiner, virt-bugs, virt-maint, xfu | |
| Target Milestone: | rc | Keywords: | TestOnly | |
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | qemu-2.5.0 | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1146460 (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: | 1055093 | |||
| Bug Blocks: | 1103193, 1146460, 1146483, 1146486 | |||
I guess this implies usb_host_full_speed_compat() needs some refinements ... Hans, any ideas? Sibiao, can you please attach lsusb -v output for the usb-stick in question both when plugged into a usb-2 port, as well as when plugged into a usb-3 port? (In reply to Hans de Goede from comment #2) > Sibiao, can you please attach lsusb -v output for the usb-stick in question > both when plugged into a usb-2 port, as well as when plugged into a usb-3 > port? My USB3.0 stick plugged into a usb-3 port info: # lsusb | grep CompUSA Bus 004 Device 002: ID 1516:6221 CompUSA # lsusb -v ... Bus 004 Device 002: ID 1516:6221 CompUSA Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 3.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 9 idVendor 0x1516 CompUSA idProduct 0x6221 bcdDevice 1.00 iManufacturer 1 iProduct 2 iSerial 3 ��� bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 44 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 3 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 3 Binary Object Store Descriptor: bLength 5 bDescriptorType 15 wTotalLength 22 bNumDeviceCaps 2 USB 2.0 Extension Device Capability: bLength 7 bDescriptorType 16 bDevCapabilityType 2 bmAttributes 0x00000002 Link Power Management (LPM) Supported SuperSpeed USB Device Capability: bLength 10 bDescriptorType 16 bDevCapabilityType 3 bmAttributes 0x00 wSpeedsSupported 0x000e Device can operate at Full Speed (12Mbps) Device can operate at High Speed (480Mbps) Device can operate at SuperSpeed (5Gbps) bFunctionalitySupport 1 Lowest fully-functional device speed is Full Speed (12Mbps) bU1DevExitLat 10 micro seconds bU2DevExitLat 2047 micro seconds Device Status: 0x0000 (Bus Powered) --------------------------------------------------------------------------- My USB3.0 stick plugged into a usb-2 port info: # lsusb | grep CompUSA Bus 001 Device 005: ID 1516:6221 CompUSA # lsusb -v ... Bus 001 Device 005: ID 1516:6221 CompUSA Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x1516 CompUSA idProduct 0x6221 bcdDevice 1.00 iManufacturer 1 iProduct 2 iSerial 3 ��� bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Binary Object Store Descriptor: bLength 5 bDescriptorType 15 wTotalLength 22 bNumDeviceCaps 2 USB 2.0 Extension Device Capability: bLength 7 bDescriptorType 16 bDevCapabilityType 2 bmAttributes 0x00000002 Link Power Management (LPM) Supported SuperSpeed USB Device Capability: bLength 10 bDescriptorType 16 bDevCapabilityType 3 bmAttributes 0x00 wSpeedsSupported 0x000e Device can operate at Full Speed (12Mbps) Device can operate at High Speed (480Mbps) Device can operate at SuperSpeed (5Gbps) bFunctionalitySupport 1 Lowest fully-functional device speed is Full Speed (12Mbps) bU1DevExitLat 10 micro seconds bU2DevExitLat 2047 micro seconds Device Status: 0x0000 (Bus Powered) I just tested 2 similar sticks with usbredir + a Linux guest and it works fine. Sibiao, what os are you using as guest? If windows can you please retest with a Linux guest? And if a Linux guest also does not work, can you please re-test with Spice's usbredir instead of using usb-host ? (In reply to Hans de Goede from comment #4) > I just tested 2 similar sticks with usbredir + a Linux guest and it works > fine. Right, passthrough the usb via usbredir did not hit this issue(I just test the rhel7 guest), all of them can work well without any qemu warning message. I will send a email to you for discus the speed problem. > Sibiao, what os are you using as guest? If windows can you please retest > with a Linux guest? The rhel guest and windows guest has little different when the USB3.0 stick inserted from the original interface port(2.0): the usb stick work well in rhel guest but cann't work in windows guest. I test the passthrough from usb-host with rhel7.0 guest: 1.Passthrough from usb-host: USB3.0 stick + original interface port(2.0) + uhci controller --------> the usb stick work well in guest without any warning message, 480 Mb/s -usb -device usb-host,hostbus=1,hostaddr=7,id=usb-stick Warning: option deprecated, use lost_tick_policy property of kvm-pit instead. QEMU 1.5.3 monitor - type 'help' for more information (qemu) (qemu) c (qemu) (qemu) info usb Device 0.1, Port 1, Speed 480 Mb/s, Product 2.Passthrough from usb-host: USB3.0 stick + PCI-E 2xUSB3.0 expansion card port(3.0) + uhci controller --------> fail to work in guest and qemu gave warning message. -usb -device usb-host,hostbus=4,hostaddr=3,id=usb-stick Warning: option deprecated, use lost_tick_policy property of kvm-pit instead. QEMU 1.5.3 monitor - type 'help' for more information (qemu) c Warning: speed mismatch trying to attach usb device "" (super speed) to bus "usb-bus.0", port "1" (full speed) (qemu) info usbqemu-kvm: Warning: speed mismatch trying to attach usb device "" (super speed) to bus "usb-bus.0", port "1" (full speed) Device 0.0, Port 1, Speed 5000 Mb/s, Product (qemu) qemu-kvm: Warning: speed mismatch trying to attach usb device "" (super speed) to bus "usb-bus.0", port "1" (full speed) (qemu) info usb Device 0.0, Port 1, Speed 5000 Mb/s, Product > And if a Linux guest also does not work, can you please re-test with Spice's > usbredir instead of using usb-host ? usb_host_full_speed_compat() is only called for usb 2.0 devices, not for usb 3.0 devices. The actual speed the device is running on counts, i.e. for usb3 sticks plugged into a usb2 port (therefore running at usb2 highspeed) the compat check is done, for usb3 sticks plugged into usb3 port the check is not done. So, that explains why comment #5 test #2 errors out. Comment #5 test #1 showing different results on windows vs. linux guests indicates that windows is more strict in parameter checking and refuses to accept the usb2/3 device on a usb1 port. /me thinks it is time to simply drop usb_host_full_speed_compat(). ehci emulation is stable and supported through the full stack these days, and you should better use ehci anyway for performance reasons. Hans, what do you think? Hi, (In reply to Gerd Hoffmann from comment #6) > usb_host_full_speed_compat() is only called for usb 2.0 devices, not for usb > 3.0 devices. The actual speed the device is running on counts, i.e. for > usb3 sticks plugged into a usb2 port (therefore running at usb2 highspeed) > the compat check is done, for usb3 sticks plugged into usb3 port the check > is not done. > > So, that explains why comment #5 test #2 errors out. > > Comment #5 test #1 showing different results on windows vs. linux guests > indicates that windows is more strict in parameter checking and refuses to > accept the usb2/3 device on a usb1 port. > > /me thinks it is time to simply drop usb_host_full_speed_compat(). ehci > emulation is stable and supported through the full stack these days, and you > should better use ehci anyway for performance reasons. Hans, what do you > think? I tend to agree. It was only ever introduced to avoid regressions for people using usb (host or net) redir with usb-2 devices while not using the new ehci emulation, because otherwise their use-case would regress. I guess some people may still be using such a config, but it is time for them to move on now. So I'm fine with dropping the check. (In reply to Hans de Goede from comment #7) > > /me thinks it is time to simply drop usb_host_full_speed_compat(). ehci > > emulation is stable and supported through the full stack these days, and you > > should better use ehci anyway for performance reasons. Hans, what do you > > think? > > I tend to agree. It was only ever introduced to avoid regressions for people > using usb (host or net) redir with usb-2 devices while not using the new > ehci emulation, because otherwise their use-case would regress. I guess some > people may still be using such a config, but it is time for them to move on > now. So I'm fine with dropping the check. Hmm, if we do this we should make similar changes to usbredir.c which does similar checks. Note I've just filed a related RFE for qemu, based on a mail from Sibiao. usbredir does something similar to usb_host_full_speed_compat() not only for redirecting usb-2 speed devices to uhci, but also for usb-3 speed devices to ehci. Although the former is something which is probably better dealt with by telling users to just configure there vms with ehci support, I believe the latter will still make sense for a while, ie when running older guest os-es which don't support xhci. See bug 1055093. see: upstream commit b88a3e01f5718d5da538bfe072cc8452107badca [ reworks port speed compatibility checks ] Please retest with this test build: http://people.redhat.com/ghoffman/bz1103193/ Doesn't reproduce locally, please reset with latest qemu 2.5 builds. Hi Jing, Could you reply comment17? Best Regards, Junyi Reproduced the issue on old version: Version-Release number of selected component (if applicable): qemu-kvm-1.5.3-30.el7.x86_64 host:kernel-3.10.0-64.el7.x86_64 guest:kernel-3.10.0-64.el7.x86_64 Steps to Reproduce: 1.plug usb usb3.0 stick to usb2.0 port then boot up guest with commands: /usr/libexec/qemu-kvm \ -name guest \ -m 4096 \ -smp 1 \ -monitor stdio \ -vnc 0:58 \ -qmp tcp:0:9998,server,nowait \ -device virtio-scsi-pci,bus=pci.0,id=x \ -device scsi-hd,drive=b,id=cc \ -device ich9-usb-uhci6,id=uhci \ -device usb-host,hostbus=3,hostaddr=3,id=ksks,bus=uhci.0 \ -drive file=RHEL-Server-7.3-64-virtio.qcow2,if=none,id=b,format=qcow2,cache=none \ -device virtio-net-pci,netdev=net0,id=nic0,mac=52:54:00:c4:e7:86 \ -netdev tap,id=net0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown,vhost=on \ 2.check if usb stick can work in guest #lsusb 3.plug usb usb3.0 stick to usb3.0 port then boot up guest with commands: /usr/libexec/qemu-kvm \ -name guest \ -m 4096 \ -smp 1 \ -monitor stdio \ -vnc 0:58 \ -qmp tcp:0:9998,server,nowait \ -device virtio-scsi-pci,bus=pci.0,id=x \ -device scsi-hd,drive=b,id=cc \ -device ich9-usb-uhci6,id=uhci \ -device usb-host,hostbus=3,hostaddr=3,id=ksks,bus=uhci.0 \ -drive file=RHEL-Server-7.3-64-virtio.qcow2,if=none,id=b,format=qcow2,cache=none \ -device virtio-net-pci,netdev=net0,id=nic0,mac=52:54:00:c4:e7:86 \ -netdev tap,id=net0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown,vhost=on \ 4.check if usb stick can work in guest #lsusb Actual results: No any warning information and usb3.0 stick can work in guest when plugging to usb2.0 port. Have speed mismatch warning and usb3.0 stick can't work in guest when plugging to usb3.0 port. Verified the issue on the latest build: Version-Release number of selected component (if applicable): qemu-kvm-rhev-2.6.0-24.el7.x86_64 host：kernel-3.10.0-492.el7.x86_64 guest:kernel-3.10.0-492.el7.x86_64 Steps to Verify: The same steps as above Actual results: No any warning information and usb stick can work in guest when plugging to usb2.0 port or usb 3.0 port. Hi Gerd I can't reproduce that usb 3.0 stick cant't work when plug it to usb2.0 port. I would like to know if we can ignore it and change status to verified or tell me how to do it. Please retest once bug 1055093 is fixed. I think it's necessary to explain the test result about comment 25.I don't know why,sometimes,the usb3.0 stick was identified as usb2.0 deivce when plugging to usb3.0 port.I retest when confirming it was identified as usb3.0 deivce when plugging to usb3.0 port.The test actual results is :Have speed mismatch warning and usb3.0 stick can't found in the guest.So the bug hasn't been fixed yet.So please ignore the verified results in comment 25. 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 |
Description of problem: Insert a usb3.0 stick to host from the original interface port(2.0) and then boot guest with this stich passthrough to guest using uhci controller. it boot up successfully but cann't work. The 3.0 usb stick must be passed through using ehci (or xhci). So qemu should quit with friendly prompt, like "Warning: speed mismatch...". BTW, if insert usb3.0 stick to host from the PCI-E 2xUSB3.0 expansion card port(3.0), and then do the same test that qemu will give a speed mismatch warning and the stick cann't work in guest correctly. qemu) c Warning: speed mismatch trying to attach usb device "" (super speed) to bus "usb-bus.0", port "2.1" (full speed) (qemu) (qemu) qemu-kvm: Warning: speed mismatch trying to attach usb device "" (super speed) to bus "usb-bus.0", port "2.1" (full speed) Version-Release number of selected component (if applicable): host info: # uname -r && rpm -q qemu-kvm 3.10.0-64.el7.x86_64 qemu-kvm-1.5.3-30.el7.x86_64 guest info: 3.10.0-64.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1.insert a usb3.0 stick to host from the original interface. 2.boot guest with this stich passthrough to guest using uhci controller. e.g:# /usr/libexec/qemu-kvm -M pc....-usb -device usb-host,hostbus=1,hostaddr=5,id=usb-stick (qemu) info usb Device 0.1, Port 1, Speed 12 Mb/s, Product QEMU USB Tablet Device 0.2, Port 2, Speed 12 Mb/s, Product QEMU USB Hub Device 0.3, Port 2.1, Speed 480 Mb/s, Product (qemu) info qtree ... dev: piix3-usb-uhci, id "" masterbus = <null> firstport = 0 bandwidth = 1280 maxframes = 128 addr = 01.2 romfile = <null> rombar = 1 multifunction = off command_serr_enable = on class USB controller, addr 00:01.2, pci id 8086:7020 (sub 1af4:1100) bar 4: i/o at 0xc040 [0xc05f] ... dev: usb-host, id "usb-stick" hostbus = 1 hostaddr = 5 hostport = <null> vendorid = 0x0 productid = 0x0 isobufs = 4 isobsize = 32 bootindex = -1 loglevel = 2 pipeline = on port = <null> serial = <null> full-path = on addr 0.3, port 2.1, speed 480, name , attached ... Actual results: after step 2, the guest boot up successfully without any speed mismatch warning, but the stick cann't work in guest. Expected results: it's better that qemu should quit with friendly prompt, like "Warning: speed mismatch...". Additional info: # /usr/libexec/qemu-kvm -M pc -S -cpu SandyBridge,hv_spinlocks=0x1fff,hv_relaxed,hv_vapic -enable-kvm -m 2048 -smp 2,sockets=2,cores=1,threads=1 -no-kvm-pit-reinjection -usb -device usb-tablet,id=input0 -name sluo -uuid 990ea161-6b67-47b2-b803-19fb01d30d30 -rtc base=localtime,clock=host,driftfix=slew -device virtio-serial-pci,id=virtio-serial0,max_ports=16,vectors=0,bus=pci.0,addr=0x3 -chardev socket,id=channel1,path=/tmp/helloworld1,server,nowait -device virtserialport,chardev=channel1,name=com.redhat.rhevm.vdsm,bus=virtio-serial0.0,id=port1 -chardev socket,id=channel2,path=/tmp/helloworld2,server,nowait -device virtserialport,chardev=channel2,name=com.redhat.rhevm.vdsm,bus=virtio-serial0.0,id=port2 -drive file=/home/en_windows_server_2012_r2_x64.raw,if=none,id=drive-virtio-disk,format=raw,cache=none,aio=native,werror=stop,rerror=stop -device virtio-blk-pci,vectors=0,bus=pci.0,addr=0x4,scsi=off,drive=drive-virtio-disk,id=virtio-disk,bootindex=1 -netdev tap,id=hostnet0,vhost=on,script=/etc/qemu-ifup -device virtio-net-pci,netdev=hostnet0,id=virtio-net-pci0,mac=00:01:02:03:04:05,bus=pci.0,addr=0x5 -device virtio-balloon-pci,id=ballooning,bus=pci.0,addr=0x6 -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -k en-us -boot menu=on -qmp tcp:0:4444,server,nowait -vnc :1 -spice disable-ticketing,port=5931 -vga qxl -monitor stdio -device usb-host,hostbus=1,hostaddr=5,id=usb-stick