For qemu2.9, rhel guest, it works fine.

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

Hi,hachen

  Please help to handle the "qa_ack" tag,thanks

aliang

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'.

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.

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.

https://lists.nongnu.org/archive/html/qemu-devel/2017-05/msg02694.html


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.

I have tried build:
https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=13214695

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

It works fine for this issue.

Fix included in qemu-kvm-rhev-2.9.0-6.el7

I test on:
kernel-3.10.0-656.el7.x86_64
qemu-kvm-rhev-2.9.0-6.el7.x86_64

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

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