From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50055) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atDCc-00035J-1f for qemu-devel@nongnu.org; Thu, 21 Apr 2016 07:55:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1atDCY-0005Eu-NF for qemu-devel@nongnu.org; Thu, 21 Apr 2016 07:55:21 -0400 Received: from hawk.thunderbug.co.uk ([149.202.60.219]:46118) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atDCY-0005Ek-FD for qemu-devel@nongnu.org; Thu, 21 Apr 2016 07:55:18 -0400 References: <5717F0E5.2090907@thunderbug.co.uk> <1461221063.28204.28.camel@redhat.com> From: Joe Clifford Message-ID: <5718BFA2.4050101@thunderbug.co.uk> Date: Thu, 21 Apr 2016 12:55:14 +0100 MIME-Version: 1.0 In-Reply-To: <1461221063.28204.28.camel@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Bug (Regression?) in hw/usb/hcd-uhci.c causes failure of ICH9 host controller and attached Xbox 360 Wireless Receiver List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: qemu-devel@nongnu.org On 21/04/16 07:44, Gerd Hoffmann wrote: > On Mi, 2016-04-20 at 22:13 +0100, Joe Clifford wrote: >> Hi folks, >> >> I'm not a coder by any stretch of the imagination so I don't have a >> patch unfortunately however, this commit: >> >> https://github.com/qemu/qemu/commit/5f77e06baa84323e5bbc96c2c7f4fe627078b210 >> >> causes the failure of the ICH9 Universal Host Controller - 2934 and the >> attached "Microsoft Common Controller For Windows Class"->"Xbox 360 >> Wireless Receiver for Windows" which is a pass-through usb device >> attached to a Q35 Windows 7 x64 VM running on a Debian Jessie host. >> >> Reverting this commit on current master (as of today) fixes the problem. >> >> I spent some time today bisecting the git master code to find this. >> >> If you require any more information for debugging, please just let me know. > Hmm, quick attempt to reproduce locally failed (slightly different > device though, a microsoft nano receiver for a mouse). It's also not > obvious how that commit breaks usb devices. > > Does the device show up in device manager? > If so: It probably has a yellow exclamation mark? > Any error description? > > Can you send the "lsusb -v" output of the device? > > cheers, > Gerd > Hi Gerd, Apologies, I should have provided more information yesterday but it was a tired, end of the day email. Hopefully the following provides a better understanding. Please excuse my assumption that the problem lies with the commit 5f77e0. I'm guessing that the problem could actually be a result of a bug in my motherboard's UEFI firmware or in the OVMF firmware or some other Qemu code that compounds the issue. I wasn't sure if it was appropriate to attach files to mailing list emails so I've uploaded them to my github account. lspci and lsub output: https://gist.github.com/7hunderbug/d4c79cc7dfb928a4d7e8bd4fb9500c5a Windows device manager screen-shots: https://github.com/7hunderbug/Qemu-Win7-screenshots Overview: Host machine: - Debian Jessie x86_64, Intel Core i5-4570S, Z87 chipset, Nvidia GTX 670, standard 3.16.0-4-amd64 kernel (backported 4.3.0-0.bpo.1-amd64 kernel also tried) - Host booted with UEFI firmware. - Unmodded EVGA NVidia card with UEFI compatible ROM. - Host OS uses Intel CPU HD4600 IGD for display. - VGA pass-through to Windows 7 VM of NVidia card using "intel_iommu=on" kernel command line and vfio module with IOMMU groups: works as expected. - PCI pass-through of host audio device - USB pass-through of three input devices, all connected to same USB 2.0 hub (mouse, keyboard, XBox wireless receiver) Guest VM: - Windows 7 x86_64 Q35 machine - OVMF-pure-efi UEFI firmware (extracted from https://www.kraxel.org/repos/jenkins/ - tried 3 different releases including edk2.git-ovmf-x64-0-20160420.b1702.g6b17c11.noarch.rpm and edk2.git-ovmf-x64-0-20160308.b1583.g231ad7d.noarch.rpm) - NVidia VGA card pass-through from host - PCI pass-through of host audio device - USB pass-through of three input devices from host Qemu command line: ./sources/qemu/x86_64-softmmu/qemu-system-x86_64 -machine q35 \ -serial none -parallel none -enable-kvm -name Windows \ -cpu host,kvm=off,acpi -smp sockets=1,cores=4,threads=1 -m 8192 \ -drive if=pflash,format=raw,readonly,file=vms/OVMF.fd \ -rtc base=localtime \ -readconfig ./sources/qemu/docs/q35-chipset.cfg \ -device ich9-ahci,id=ahci \ -drive if=virtio,id=drive0,file=vms/w7p64-g1.qcow2,format=qcow2 \ -drive if=virtio,id=drive1,file=vms/w7pro64-pf.qcow2,format=qcow2 \ -drive if=virtio,id=drive2,file=/dev/mapper/winf,format=raw,cache=none \ -device vfio-pci,host=01:00.0,multifunction=on,x-vga=on \ -device vfio-pci,host=01:00.1,multifunction=on \ -device vfio-pci,host=00:1b.0,multifunction=on \ -netdev type=tap,id=net0,ifname=tap1,script=no \ -device virtio-net-pci,netdev=net0,mac=52:54:xx:xx:xx:xx \ -device usb-host,bus=ich9-ehci-1.0,hostbus=3,hostport=2.1 \ -device usb-host,bus=ich9-ehci-2.0,hostbus=3,hostport=2.2 \ -device usb-host,bus=ich9-ehci-2.0,hostbus=3,hostport=2.4 The symptoms on booting the Windows 7 VM are: *Using Qemu compiled from master: - When booting with the device attached, sometimes the mouse and keyboard in the guest are unresponsive for a minute or so. Checking the device manager when they become responsive again shows the yellow warning triangle next to the first ICH9 UHCI device. - When booting without the device attached, then running the device manager to watch what happens, inserting the device results in it appearing as normal for ~30-50 seconds before the device manager view refreshes and the yellow warning triangle appears next to the IC9 UHCI device and the Xbox USB device disappears. (See screen-shot w7-devman1.png and w7-devman2.png). Sometimes this results in unresponsive keyboard and mouse in the guest and other times not. *Using Qemu compiled from master with commit5f77e0 reverted: - Booting with the device attached or unattached makes no difference, in both scenarios the device works as expected. (See screen-shot w7-devman3.png) This is reproducible for me every time, with my current Windows 7 image and with a freshly built image. After researching other user's problems, I suspected the issue might be related to all the pass-through USB devices being manufactured by Microsoft however, the same problem occurs with a Logitech keyboard and mouse. Regards, Joe