Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse

[Laszlo Ersek]

On 09/10/14 00:00, Gabriel L. Somlo wrote:
> Executive summary: OS X (10.9.4) works on Q35 with usb keyboard+mouse when
> booted on SeaBIOS with Chameleon , but not on OVMF [1].
> 
> [1] Recently patched acpi pm timer to boot on Q35, plus a bunch of pending
>     sata patches by Reza, cc-ed.
> 
> Command lines used to test using Fedora 20 live and OS X 10.9
> (with or without OVMF for Fedora, with OVMF or Chameleon for OS X):
> 
> bin/qemu-system-x86_64 -enable-kvm -m 2048 -machine q35 \
>   -device ide-drive,bus=ide.2,drive=CD \
>   -drive id=CD,if=none,snapshot=on,file=./Fed-Live-Desktop-x86_64-20-1.iso \
>   -usb -device usb-kbd -device usb-mouse \
>   [ -bios OVMF.fd ]
> 
> bin/qemu-system-x86_64 -enable-kvm -m 2048 -cpu core2duo -machine q35 \
>   -device isa-applesmc,osk="our...Inc" \
>   -netdev user,id=usr0 -device e1000-82545em,netdev=usr0,id=vnet0 \
>   -device ide-drive,bus=ide.2,drive=MacHDD \
>   -drive id=MacHDD,if=none,snapshot=on,file=./mac_10.9.img \
>   -usb -device usb-kbd -device usb-mouse \
>   [ -kernel ./chameleon_boot | -bios OVMF.fd ]
> 
> In all cases, we get this from "info qtree":
> 
>       dev: ich9-usb-uhci3, id ""
>         masterbus = "usb-bus.0"
>         firstport = 4 (0x4)
>         bandwidth = 1280 (0x500)
>         maxframes = 128 (0x80)
>         addr = 1d.2
>         romfile = ""
>         rombar = 1 (0x1)
>         multifunction = true
>         command_serr_enable = true
>         class USB controller, addr 00:1d.2, pci id 8086:2936 (sub 1af4:1100)
>         bar 4: i/o at 0xc0a0 [0xc0bf]
>       dev: ich9-usb-uhci2, id ""
>         masterbus = "usb-bus.0"
>         firstport = 2 (0x2)
>         bandwidth = 1280 (0x500)
>         maxframes = 128 (0x80)
>         addr = 1d.1
>         romfile = ""
>         rombar = 1 (0x1)
>         multifunction = true
>         command_serr_enable = true
>         class USB controller, addr 00:1d.1, pci id 8086:2935 (sub 1af4:1100)
>         bar 4: i/o at 0xc0c0 [0xc0df]
>       dev: ich9-usb-uhci1, id ""
>         masterbus = "usb-bus.0"
>         firstport = 0 (0x0)
>         bandwidth = 1280 (0x500)
>         maxframes = 128 (0x80)
>         addr = 1d.0
>         romfile = ""
>         rombar = 1 (0x1)
>         multifunction = true
>         command_serr_enable = true
>         class USB controller, addr 00:1d.0, pci id 8086:2934 (sub 1af4:1100)
>         bar 4: i/o at 0xc0e0 [0xc0ff]
>       dev: ich9-usb-ehci1, id ""
>         maxframes = 128 (0x80)
>         addr = 1d.7
>         romfile = ""
>         rombar = 1 (0x1)
>         multifunction = true
>         command_serr_enable = true
>         class USB controller, addr 00:1d.7, pci id 8086:293a (sub 1af4:1100)
>         bar 0: mem at 0x82021000 [0x82021fff]
>         bus: usb-bus.0
>           type usb-bus
>           dev: usb-mouse, id ""
>             port = ""
>             serial = ""
>             full-path = true
>             msos-desc = true
>             addr 0.2, port 2, speed 12, name QEMU USB Mouse, attached
>           dev: usb-kbd, id ""
>             display = ""
>             port = ""
>             serial = ""
>             full-path = true
>             msos-desc = true
>             addr 0.1, port 1, speed 12, name QEMU USB Keyboard, attached
> 
> 
> In all *working* cases (all except OSX+OVMF) the guest os (mac or linux)
> reports the keyboard and mouse as connected to ich9-usb-uhci1 (dev. id 
> 0x2934),
> contradicting the qtree output. On linux I got this out of 'dmesg':
> 
> input: QEMU QEMU USB Keyboard as 
> /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0/input/input3
> hid-generic 0003:0627:0001.0001: input,hidraw0: USB HID v1.11 Keyboard [QEMU 
> QEMU USB Keyboard] on usb-0000:00:1d.0-1/input0
> input: QEMU QEMU USB Mouse as 
> /devices/pci0000:00/0000:00:1d.0/usb2/2-2/2-2:1.0/input/input4
> hid-generic 0003:0627:0001.0002: input,hidraw1: USB HID v0.01 Mouse [QEMU 
> QEMU USB Mouse] on usb-0000:00:1d.0-2/input0
> 
> On OS X (with Chameleon), I get the same results using System Profiler.
> 
> 
> So at this point I'm wondering why guests and "info qtree" are contradictory,
> and whether the combination of OVMF and OS X tickle some qemu usb emulation
> bug differently than all other (working) combinations ?
> 
> 
> BTW, doing something like:
> 
>   -usb -device ich9-usb-uhci1,id=uhci1 -device usb-kbd,bus=uhci1.0 \
>        -device ich9-usb-uhci2,id=uhci2 -device usb-mouse,bus=uhci2.0
> 
> to completely override uhci1 and uhci2, and force the keyboard and mouse
> to connect there causes OS X to start working on OVMF.
> 
> 
> Not sure how I'd force the keyboard and mouse onto the default uhci1 and/or
> uhci2 (from the qtree perspective), since they're given empty IDs by default
> (and my qemu command line kung-fu is weak in this area).
> 
> 
> Any thoughts or comments (or tips for further debugging) much appreciated.

My take is that "MdeModulePkg/Bus/Pci/EhciDxe" does something to the
devices that trips up OSX, but doesn't trip up Linux. Try building OVMF
without this driver, and see what happens.

The following (in the driver's INF file) could be relevant:

#  Note that EhciDxe driver is enhanced to guarantee that the EHCI
#  controller get attached to the EHCI controller before the UHCI driver
#  attaches to the companion UHCI controller.  This way avoids the
#  control transfer on a shared port between EHCI and companion host
#  controller when UHCI gets attached earlier than EHCI and a USB 2.0
#  device inserts.

I think that the qtree output is correct, and the working cases work
because the guests can somehow "downgrade" the devices from 2.0 to 1.1
(or maybe 1.0, no clue). Ie. the mouse / tablet is plugged in a shared
port, and after some fiddling, UHCI wins (in the working cases). OVMF's
EHCI driver probably leaves things in such a state that OSX chokes on them.

Apologies if I just wrote a load of BS. :)

Laszlo