From: Joe Clifford <joe@thunderbug.co.uk>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: qemu-devel@nongnu.org
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 [thread overview]
Message-ID: <5718BFA2.4050101@thunderbug.co.uk> (raw)
In-Reply-To: <1461221063.28204.28.camel@redhat.com>
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
next prev parent reply other threads:[~2016-04-21 11:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-20 21:13 [Qemu-devel] Bug (Regression?) in hw/usb/hcd-uhci.c causes failure of ICH9 host controller and attached Xbox 360 Wireless Receiver Joe Clifford
2016-04-21 6:44 ` Gerd Hoffmann
2016-04-21 11:55 ` Joe Clifford [this message]
2016-04-21 14:17 ` Gerd Hoffmann
2016-04-21 15:41 ` Joe Clifford
2016-04-21 15:51 ` Joe Clifford
2016-04-22 10:05 ` Gerd Hoffmann
2016-04-22 10:04 ` Gerd Hoffmann
2016-04-22 10:32 ` joe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5718BFA2.4050101@thunderbug.co.uk \
--to=joe@thunderbug.co.uk \
--cc=kraxel@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).