qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Bug (Regression?) in hw/usb/hcd-uhci.c causes failure o


From: Joe Clifford
Subject: Re: [Qemu-devel] Bug (Regression?) in hw/usb/hcd-uhci.c causes failure of ICH9 host controller and attached Xbox 360 Wireless Receiver
Date: Thu, 21 Apr 2016 12:55:14 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.0

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]