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

[Gerd Hoffmann <kraxel@redhat.com>]

  Hi,

> 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 ?

It's due to the way how usb1 compatibility was implemented when ehci was
introduced ...

Each usb 2.0 port is linked to both uhci and ehci controller.  ehci
controls the port routing (i.e. whenever a device shows up @ uhci or
ehci).  There is one global bit and one per-port bit which control the
routing.

The global bit says whenever the ports should be routed to ehci by
default or not.  EHCI driver software is supposed to flip that bit at
initialization time to get all devices routed to ehci.  Power-on default
is route everything to uhci, so if the OS knows nothing about ehci all
usb devices will show up on the uhci companion.

The per-port bit should be flipped by the ehci driver for usb1 devices,
so they are handed over to uhci as ehci supports usb2 devices only.


In qemu this is implemented by having ehci managing the usb bus and uhci
registering its ports as companion ports.  ehci emulation will either
handle the devices itself or call uhci, depending on how the guest has
configured the routing.

There is even a basic test case for that:  tests/usb-hcd-ehci-test.c

Because ehci manages the bus the usb devices show up on ehci in 'info
qtree', no matter how the port routing is configured.

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

Pure uhci working fine hints it most likely is a bug somewhere in the
port routing code.  Could be in ovmf, but could be qemu too.  You can't
force it from outsize, port routing is guest business.

What happens if you build ovmf with uhci but without ehci driver?  Does
that work?

cheers,
  Gerd