Bug 1447581 - [RHEV7.4] [usb-hub] input devices under usb hub don't work on win2016 with xhci
Summary: [RHEV7.4] [usb-hub] input devices under usb hub don't work on win2016 with xhci
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.4
Hardware: x86_64
OS: Windows
Target Milestone: rc
: ---
Assignee: Ladi Prosek
QA Contact: hachen
Depends On:
TreeView+ depends on / blocked
Reported: 2017-05-03 09:05 UTC by hachen
Modified: 2017-08-02 04:38 UTC (History)
17 users (show)

Fixed In Version: qemu-kvm-rhev-2.9.0-6.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-08-02 04:38:29 UTC
Target Upstream Version:

Attachments (Terms of Use)

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 hachen 2017-05-03 09:05:51 UTC
Description of problem:
when put input devices under one usb hub ,win2016 guest hangs after everything loaded for xhci.

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


How reproducible:3/3

Steps to Reproduce:
1.start guest
/usr/libexec/qemu-kvm \
    -name 'avocado-vt-vm1'  \
    -sandbox off  \
    -machine pc  \
    -nodefaults  \
    -vga std  \
    -device nec-usb-xhci,id=usb1,bus=pci.0 \
    -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.0 \
    -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:61:62:63:64:65,id=idyscRss,vectors=4,netdev=idFoNLxt,bus=pci.0  \
    -netdev tap,id=idFoNLxt \
    -m 8192  \
    -smp 8,cores=4,threads=1,sockets=2  \
    -cpu 'SandyBridge',+kvm_pv_unhalt,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 \
    -vnc :1  \
    -rtc base=localtime,clock=host,driftfix=slew  \
    -boot order=cdn,once=c,menu=off,strict=off \
    -enable-kvm \
    -monitor stdio \
    -device usb-hub,id=usbhub,bus=usb1.0,port=1\
    -device usb-mouse,id=usbmouse,bus=usb1.0,port=1.1\
    -device usb-kbd,id=usbkbd,bus=usb1.0,port=1.2\
    -device usb-tablet,id=usbtablet,bus=usb1.0,port=1.3\

Actual results:
win2016 guest hangs after everything loaded

Expected results:
win2016 guest works well

Additional info:

Comment 2 hachen 2017-05-03 09:08:38 UTC
For qemu2.9, rhel guest, it works fine.

And I have tested it on qemu 2.8, same result, win2016 guest hangs.

Comment 3 aihua liang 2017-05-04 02:31:53 UTC

  Please help to handle the "qa_ack" tag,thanks


Comment 4 Ladi Prosek 2017-05-10 08:55:22 UTC
Fixing bug summary as this is not a true hang. The devices just don't work behind a hub so it's not possible to interact with the guest and it appears 'hung'.

Comment 5 Ladi Prosek 2017-05-10 14:43:04 UTC
And one more update because this is not xhci specific. I can reproduce with uhci also.

  -device piix4-usb-uhci,id=usb1 \
  -device usb-hub,id=usbhub,bus=usb1.0,port=1 \
  -device usb-mouse,id=usbmouse,bus=usb1.0,port=1.1 \

As long as the input device is sending data (mouse is moving), all is good. The device stops working a few seconds after the last input event when the port goes into suspend and then never properly wakes up. Disabling and re-enabling the USB Hub device in Device manager fixes it. But only until the next few seconds of inactivity when it stalls again.

The following patch fixes it for xhci:

@@ -208,6 +208,7 @@ static void usb_hub_wakeup(USBPort *port1)
     USBHubPort *port = &s->ports[port1->index];
     if (port->wPortStatus & PORT_STAT_SUSPEND) {
+        port->wPortStatus &= ~PORT_STAT_SUSPEND;
         port->wPortChange |= PORT_STAT_C_SUSPEND;
         usb_wakeup(s->intr, 0);

uhci needs one additional tweak in uhci_wakeup.

I'll look at the spec to try to understand what's going on here and if this is the right fix. Adding Gerd.

Comment 6 Ladi Prosek 2017-05-11 13:23:49 UTC
And I'm putting the "with xhci" back because these are two different issues.

I have convinced myself that the patch in comment #5 is correct and posted it to qemu-devel. It fixes the bug observed with xhci on Windows.


Now the uhci issue manifests in the same way, i.e. remote wakeup doesn't work for suspended devices. But it doesn't need a hub to reproduce. The problem is that Windows doesn't set the UHCI_PORT_SUSPEND flag, despite correctly arming the port for remote wakeup. Thus uhci_wakeup is a no-op and the VM doesn't get any kind of notification that the device has woken up, leading to the issue described in comment #5.

Weirdly, Windows does the right thing with piix3-usb-uhci (Intel 82371SB) and is broken only with piix4-usb-uhci (Intel 82371AB). As far as I can tell, the two chips have identical implementation in QEMU and differ only in the PCI device ID. Windows drives both with usbuhci.sys so the driver must internally modify its behavior based on the device ID for some odd reason. I am going to treat this with lower priority because it requires time-consuming reverse engineering and piix3-usb-uhci is libvirt's default uhci controller anyway.

Comment 8 hachen 2017-05-22 02:57:11 UTC
I have tried build:

more info, please refer to https://bugzilla.redhat.com/show_bug.cgi?id=1449991

It works fine for this issue.

Comment 9 Miroslav Rezanina 2017-05-23 08:15:13 UTC
Fix included in qemu-kvm-rhev-2.9.0-6.el7

Comment 11 hachen 2017-05-24 07:56:11 UTC
I test on:

The Win2016 guest can boot up, the usb mouse and kbd work well.
Bug verified.

Comment 13 errata-xmlrpc 2017-08-02 04:38:29 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.


Note You need to log in before you can comment on or make changes to this bug.