Bug 1507820

Summary: one of usb devices under a hub is not recognized by win2016 guest with nec-xhci
Product: Red Hat Enterprise Linux Advanced Virtualization Reporter: hachen <hachen>
Component: qemu-kvmAssignee: Gerd Hoffmann <kraxel>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.0CC: chayang, coli, ddepaula, fugz1, juzhang, knoel, kraxel, liupeng17, ngu, qzhang, rbalakri, tyu1, virt-maint, xiaohli, xuma
Target Milestone: rcKeywords: Reopened
Target Release: 8.0   
Hardware: x86_64   
OS: Unspecified   
Whiteboard:
Fixed In Version: qemu-kvm-4.1.0-1.module+el8.1.0+3966+4a23dca1 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-11-06 07:10:39 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:
Attachments:
Description Flags
Boot_up_with_tablet.png
none
After_hotunplug_tablet.png none

Description hachen 2017-10-31 09:03:00 UTC 
Description of problem:
When attach multiple usb devices eg. 6 or more usb-mouses under a usb hub, one of usb devices under is not recognized by win2016 guest 


Version-Release number of selected component (if applicable):

Host kernel : kernel-3.10.0-693.el7.x86_64
qemu: qemu-kvm-rhev-2.9.0-16.el7_4.9.x86_64 (it seems not 100% reproducible)

qemu-kvm-rhev-2.9.0-16.el7_4.5.x86_64 (100% reproducible)


How reproducible:


Steps to Reproduce:
1. boot guest with
/usr/libexec/qemu-kvm \
    -name 'avocado-vt-vm1'  \
    -sandbox off  \
    -machine pc  \
    -nodefaults  \
    -vga std  \
    -device pvpanic,ioport=0x505,id=idAZN8Ia  \
    -device nec-usb-xhci,id=usbtest,bus=pci.0,addr=0x3 \
    -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.0,addr=0x4 \
    -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:e4:e5:e6:e7:e8,id=idOCesHt,vectors=4,netdev=id4lq6hH,bus=pci.0,addr=0x5  \
    -netdev tap,id=id4lq6hH,vhost=on \
    -m 8192  \
    -smp 4,cores=2,threads=1,sockets=2  \
    -cpu 'Westmere',+kvm_pv_unhalt,hv_relaxed,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-hub,id=usb-d0,bus=usbtest.0,port=1 \
    -device usb-mouse,id=usb-d1,bus=usbtest.0,port=1.1 \
    -device usb-mouse,id=usb-d2,bus=usbtest.0,port=1.2 \
    -device usb-mouse,id=usb-d3,bus=usbtest.0,port=1.3 \
    -device usb-mouse,id=usb-d4,bus=usbtest.0,port=1.4 \
    -device usb-mouse,id=usb-d5,bus=usbtest.0,port=1.5 \
    -device usb-mouse,id=usb-d6,bus=usbtest.0,port=1.6 \
    -device usb-mouse,id=usb-d7,bus=usbtest.0,port=1.7 \
    -device usb-mouse,id=usb-d8,bus=usbtest.0,port=1.8  \
    -vnc :0  \
    -rtc base=localtime,clock=host,driftfix=slew  \
    -boot menu=off,strict=off,order=cdn,once=c \
    -enable-kvm \
    -monitor stdio \

2. info usb
QEMU 2.9.0 monitor - type 'help' for more information
(qemu) info usb
  Device 0.1, Port 1, Speed 12 Mb/s, Product QEMU USB Hub, ID: usb-d0
  Device 0.2, Port 1.1, Speed 12 Mb/s, Product QEMU USB Mouse, ID: usb-d1
  Device 0.9, Port 1.2, Speed 12 Mb/s, Product QEMU USB Mouse, ID: usb-d2
  Device 0.8, Port 1.3, Speed 12 Mb/s, Product QEMU USB Mouse, ID: usb-d3
  Device 0.7, Port 1.4, Speed 12 Mb/s, Product QEMU USB Mouse, ID: usb-d4
  Device 0.6, Port 1.5, Speed 12 Mb/s, Product QEMU USB Mouse, ID: usb-d5
  Device 0.5, Port 1.6, Speed 12 Mb/s, Product QEMU USB Mouse, ID: usb-d6
  Device 0.4, Port 1.7, Speed 12 Mb/s, Product QEMU USB Mouse, ID: usb-d7
  Device 0.3, Port 1.8, Speed 12 Mb/s, Product QEMU USB Mouse, ID: usb-d8

3. login to win2016 guest, run cmd: wmic path Win32_USBControllerDevice get Dependent | find "USB"

C:\>wmic path Win32_USBControllerDevice get Dependent | find "USB"
\\WIN-VGMLPPUT9E5\root\cimv2:Win32_PnPEntity.DeviceID="USB\ROOT_HUB30\4&8703BE7&0&0"                       
\\WIN-VGMLPPUT9E5\root\cimv2:Win32_PnPEntity.DeviceID="USB\VID_0409&PID_55AA\MSFT20314159-0000:00:03.0-1"  
\\WIN-VGMLPPUT9E5\root\cimv2:Win32_PnPEntity.DeviceID="USB\VID_0000&PID_0000\6&15E6C34A&0&3"    <-------- not recognized             
\\WIN-VGMLPPUT9E5\root\cimv2:Win32_PnPEntity.DeviceID="USB\VID_0627&PID_0001\42"                           
\\WIN-VGMLPPUT9E5\root\cimv2:Win32_PnPEntity.DeviceID="USB\VID_0627&PID_0001\6&15E6C34A&0&2"               
\\WIN-VGMLPPUT9E5\root\cimv2:Win32_PnPEntity.DeviceID="USB\VID_0627&PID_0001\6&15E6C34A&0&4"               
\\WIN-VGMLPPUT9E5\root\cimv2:Win32_PnPEntity.DeviceID="USB\VID_0627&PID_0001\6&15E6C34A&0&1"               
\\WIN-VGMLPPUT9E5\root\cimv2:Win32_PnPEntity.DeviceID="USB\VID_0627&PID_0001\6&15E6C34A&0&8"               
\\WIN-VGMLPPUT9E5\root\cimv2:Win32_PnPEntity.DeviceID="USB\VID_0627&PID_0001\6&15E6C34A&0&6"               
\\WIN-VGMLPPUT9E5\root\cimv2:Win32_PnPEntity.DeviceID="USB\VID_0627&PID_0001\6&15E6C34A&0&5"             

If you check the 'Device manager' or 'control panel', there was only 7 usb mouses.

Actual results:


Expected results:
All devices are recognized


Additional info:
Tried 3 times on:
kernel-3.10.0-749.el7.x86_64
qemu-kvm-rhev-2.10.0-3.el7.x86_64 
It did not happen
Comment 2 Gerd Hoffmann 2017-11-01 08:49:17 UTC 
> Additional info:
> Tried 3 times on:
> kernel-3.10.0-749.el7.x86_64
> qemu-kvm-rhev-2.10.0-3.el7.x86_64 
> It did not happen

So we can close it as it is already fixed for 7.5, right?
(I don't think we need a 7.4.z backport)
Comment 3 Gu Nini 2017-11-01 10:05:53 UTC 
Created attachment 1346393 [details]
Boot_up_with_tablet.png

(In reply to Gerd Hoffmann from comment #2)
> 
> So we can close it as it is already fixed for 7.5, right?
> (I don't think we need a 7.4.z backport)


Met the issue on RHEL7.5 with the same steps in bug Description but add a tablet '-device usb-tablet,id=usb-tablet,port=2':
qemu-kvm-rhev-2.10.0-3.el7.x86_64
Host kernel 3.10.0-748.el7.x86_64

Besides the bug issue, there is following problems:
1. More than one usb input device might be not recognized in the control panel
2. The usb tablet takes no effect here

Please check the attached screenshots for more details.
Comment 4 Gu Nini 2017-11-01 10:06:36 UTC 
Created attachment 1346394 [details]
After_hotunplug_tablet.png
Comment 5 Gu Nini 2017-11-01 10:16:59 UTC 
(In reply to Gu Nini from comment #3)
> 
> 
> Besides the bug issue, there is following problems:
> 1. More than one usb input device might be not recognized in the control
> panel
> 2. The usb tablet takes no effect here

Please note with a tablet, it's easy to reproduce the bug. And for the tablet takes no effect issue, should we report another bug?

> 
> Please check the attached screenshots for more details.
Comment 6 Gerd Hoffmann 2017-11-14 12:55:19 UTC 
https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=14547812
can you try if that build improves things?
Comment 7 Gu Nini 2017-11-16 06:16:57 UTC 
(In reply to Gerd Hoffmann from comment #6)
> https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=14547812
> can you try if that build improves things?

Yes, it turns well, i.e. all usb device could be found under 'Hardware' of 'Control Panel' and in cmd wmic output.

However, the usb tablet taking no effect issue still exists; and it's found if boot up guest with 2 or more mouses besides the tablet, there would be the issue.

(qemu) info usb
  Device 0.1, Port 1, Speed 480 Mb/s, Product QEMU USB Tablet, ID: usb-e1
  Device 0.2, Port 2, Speed 480 Mb/s, Product QEMU USB Mouse, ID: usb-d2
  Device 0.3, Port 3, Speed 480 Mb/s, Product QEMU USB Mouse, ID: usb-d3
Comment 8 Gerd Hoffmann 2017-11-16 06:51:12 UTC 
> However, the usb tablet taking no effect issue still exists; and it's found
> if boot up guest with 2 or more mouses besides the tablet, there would be
> the issue.

What does "info mice" print then?
Comment 9 Gu Nini 2017-11-16 07:16:46 UTC 
(In reply to Gerd Hoffmann from comment #8)
> > However, the usb tablet taking no effect issue still exists; and it's found
> > if boot up guest with 2 or more mouses besides the tablet, there would be
> > the issue.
> 
> What does "info mice" print then?



I have reported new bz1513861 to track the issue. The bug also occurred on linux guest, following is the 'info mice' output for a linux guest.


(qemu) info mice
  Mouse #2: QEMU PS/2 Mouse
  Mouse #4: QEMU HID Mouse
  Mouse #5: vmmouse (absolute)
  Mouse #3: QEMU HID Tablet (absolute)
* Mouse #6: QEMU HID Mouse
Comment 10 Gerd Hoffmann 2017-11-17 06:48:17 UTC 
> (qemu) info mice
>   Mouse #2: QEMU PS/2 Mouse
>   Mouse #4: QEMU HID Mouse
>   Mouse #5: vmmouse (absolute)
>   Mouse #3: QEMU HID Tablet (absolute)
> * Mouse #6: QEMU HID Mouse

As expected.  The tablet isn't the active pointer device.

If you switch to the tablet ("mouse_set 3" in monitor) it starts working I guess?
Comment 11 Gu Nini 2017-11-17 10:24:35 UTC 
(In reply to Gerd Hoffmann from comment #10)
> > (qemu) info mice
> >   Mouse #2: QEMU PS/2 Mouse
> >   Mouse #4: QEMU HID Mouse
> >   Mouse #5: vmmouse (absolute)
> >   Mouse #3: QEMU HID Tablet (absolute)
> > * Mouse #6: QEMU HID Mouse
> 
> As expected.  The tablet isn't the active pointer device.
> 
> If you switch to the tablet ("mouse_set 3" in monitor) it starts working I
> guess?


Yes, it works. Should we use the 'mouse_set' cmd in the test scenario? But it seems there is no corresponding qmp cmd.
Comment 12 Gerd Hoffmann 2017-11-17 10:42:20 UTC 
(In reply to Gu Nini from comment #11)
> (In reply to Gerd Hoffmann from comment #10)
> > > (qemu) info mice
> > >   Mouse #2: QEMU PS/2 Mouse
> > >   Mouse #4: QEMU HID Mouse
> > >   Mouse #5: vmmouse (absolute)
> > >   Mouse #3: QEMU HID Tablet (absolute)
> > > * Mouse #6: QEMU HID Mouse
> > 
> > As expected.  The tablet isn't the active pointer device.
> > 
> > If you switch to the tablet ("mouse_set 3" in monitor) it starts working I
> > guess?
> 
> 
> Yes, it works. Should we use the 'mouse_set' cmd in the test scenario? But
> it seems there is no corresponding qmp cmd.

Depends on what you want to test ...

If you want test the usb-tablet, then attach it as the only usb input device.

If you want test whenever many usb devices work correctly you can use a bunch of usb input devices for that.  They should all be visible in the guest (lspci), the guest driver should load and initialize, you can verify that.  But you can't expect that mouse events are routed to a specific device.  It depends on the order the guest initializes the devices which of them receives the events.
Comment 13 Gerd Hoffmann 2018-01-12 10:07:06 UTC 
> > Yes, it works. Should we use the 'mouse_set' cmd in the test scenario? But
> > it seems there is no corresponding qmp cmd.
> 
> Depends on what you want to test ...
> 
> If you want test the usb-tablet, then attach it as the only usb input device.
> 
> If you want test whenever many usb devices work correctly you can use a
> bunch of usb input devices for that.  They should all be visible in the
> guest (lspci), the guest driver should load and initialize, you can verify
> that.  But you can't expect that mouse events are routed to a specific
> device.  It depends on the order the guest initializes the devices which of
> them receives the events.

Closing as notabug now.  If you see behavior not matching what I described above feel free to reopen the bug with additional information.
Comment 16 Gerd Hoffmann 2019-03-05 08:14:49 UTC 
upstream commit b63e10508bee7169cfc7022805638c7358feefb5
HID devices get unique serial numbers, which should fix this one.
Needs new machine type, so something to pick up by the next rebase.
Comment 18 Michael 2019-08-29 07:28:35 UTC 
Hi All:

I am verifying this Bug. The original bug happened on RHEL7 and the fix version is on RHEL8. Thus, I would not to reproduce the original bug. Just verify the fix version on RHEL8. 

Test Version:
[1]4.18.0-139.el8.x86_64
[2]qemu-kvm-4.1.0-5.module+el8.1.0+4076+b5e41ebc.x86_64


Follow those steps verify this Bug:

[1] Boot Windows 2016 guest. Add one usb hub and attach 8 usb-mouse on the hub. 

/usr/libexec/qemu-kvm -M q35 -cpu EPYC -enable-kvm -m 7G -smp 4 -nodefaults \
... ...
-device qemu-xhci,id=xhci1,bus=pcie.0-root-port-4,addr=0x0 \
-device usb-hub,id=usb-d0,bus=xhci1.0,port=1 \
-device usb-mouse,id=usb-d1,bus=xhci1.0,port=1.1 \
-device usb-mouse,id=usb-d2,bus=xhci1.0,port=1.2 \
-device usb-mouse,id=usb-d3,bus=xhci1.0,port=1.3 \
-device usb-mouse,id=usb-d4,bus=xhci1.0,port=1.4 \
-device usb-mouse,id=usb-d5,bus=xhci1.0,port=1.5 \
-device usb-mouse,id=usb-d6,bus=xhci1.0,port=1.6 \
-device usb-mouse,id=usb-d7,bus=xhci1.0,port=1.7 \
-device usb-mouse,id=usb-d8,bus=xhci1.0,port=1.8 \


[2] Verify usb mouse inside the windows. 

"device manager" and "control panel" have 8 usb mouse. 

run cmd: wmic path Win32_USBControllerDevice get Dependent | find "USB"

\\WIN-2BGVQIBLM0S\root\cimv2:Win32_PnPEntity.DeviceID="USB\ROOT_HUB30\S&38584F00&0&0"
\\WIN-2BGVQIBLM0S\root\cimv2:Win32_PnPEntity.DeviceID="USB\VID_0409&PID_SSAA\MSFT20314159-0000:00:04.0:00.0-1"
\\WIN-2BGVQIBLM0S\root\cimv2:Win32_PnPEntity.DeviceID="USB\VID_0409&PID_0001\89126-0000:00:04.0:00.0-1.2"
\\WIN-2BGVQIBLM0S\root\cimv2:Win32_PnPEntity.DeviceID="USB\VID_0409&PID_0001\89126-0000:00:04.0:00.0-1.3"
\\WIN-2BGVQIBLM0S\root\cimv2:Win32_PnPEntity.DeviceID="USB\VID_0409&PID_0001\89126-0000:00:04.0:00.0-1.4"
\\WIN-2BGVQIBLM0S\root\cimv2:Win32_PnPEntity.DeviceID="USB\VID_0409&PID_0001\89126-0000:00:04.0:00.0-1.5"
\\WIN-2BGVQIBLM0S\root\cimv2:Win32_PnPEntity.DeviceID="USB\VID_0409&PID_0001\89126-0000:00:04.0:00.0-1.6"
\\WIN-2BGVQIBLM0S\root\cimv2:Win32_PnPEntity.DeviceID="USB\VID_0409&PID_0001\89126-0000:00:04.0:00.0-1.7"
\\WIN-2BGVQIBLM0S\root\cimv2:Win32_PnPEntity.DeviceID="USB\VID_0409&PID_0001\89126-0000:00:04.0:00.0-1.8"
\\WIN-2BGVQIBLM0S\root\cimv2:Win32_PnPEntity.DeviceID="USB\VID_0409&PID_0001\89126-0000:00:04.0:00.0-1.1"

Every device were recognized. 


Every thing looks fine. Mark this Bug as Verified. 



Thanks
Comment 21 errata-xmlrpc 2019-11-06 07:10:39 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/RHBA-2019:3723