Bug 1447581
| Summary: | [RHEV7.4] [usb-hub] input devices under usb hub don't work on win2016 with xhci | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | hachen <hachen> |
| Component: | qemu-kvm-rhev | Assignee: | Ladi Prosek <lprosek> |
| Status: | CLOSED ERRATA | QA Contact: | hachen <hachen> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.4 | CC: | ailan, aliang, chayang, coli, hachen, juzhang, knoel, kraxel, lprosek, michen, mrezanin, ngu, pingl, shuang, virt-maint, xuhan, xuwei |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Windows | ||
| Whiteboard: | |||
| Fixed In Version: | qemu-kvm-rhev-2.9.0-6.el7 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-08-02 04:38:29 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: | |||
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 |
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): HOST: kernel-3.10.0-656.el7.x86_64 qemu-kvm-rhev-2.9.0-2.el7.x86_64 GUEST: kernel-3.10.0-656.el7.x86_64 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: