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
