qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

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