OVMF, Q35 and USB keyboard/mouse

On Fri, Sep 12, 2014 at 03:59:52PM -0400, Gabriel L. Somlo wrote:
> On Fri, Sep 12, 2014 at 08:26:01PM +0200, Paolo Bonzini wrote:
> > So it could be an OVMF bug related to multifunction devices.
> > 
> > Well, you could try moving devices around in different functions.
> > You could try moving ehci1 to 0 and the UHCIs to 1/2/7.
> > 
> > Or drop uhci2/uhci3 and move the two remaining devices around.  Once you
> > have three combinations that work (e.g. 0/4, 0/6, 0/7) you could use it
> > to add three UHCI controllers (in the above examples, it would be 0/1/2/7).
> > 
> > Remember that one of the two must be xx.0, the other can be anything
> > from xx.1 to xx.7.
> 
> I moved things around as you suggested (from hw/usb/hcd-ehci-pci.c and
> the ich9_1d[] array).
> 
> No matter which PCI function gets assigned to which device, and no
> matter which order the uhci1/2/3 devices are listed in ich9_1d[],
> it's *always* uhci3 (dev.id. 2936) and ehci being shown, and uhci1&2
> end up missing.
> 
> Interestingly, if I comment out uhci3, it's only ehci that shows up,
> not uhci1 or uhci2 (even though one of them is 00:1d.0). 
> 
> 
> Feels like there's some thing "magical" about the uhci3 name or device
> ID. Maybe at this point I should go fishing in the edk2 source :) 

Even more interesting, if I use uhci3 for all three uhci devices in
qemu:



they *all* get detected and work great on ovmf+osx. Slow kbd+mouse
get routed automatically to one of them, and work fine. The only
differences I can see between them (in hw/usb/hcd-uhci.c) is
the name string and "irq_pin" field. Not sure yet if that's likely
to point to an explanation...

Right now I'm wondering if ovmf ehci and/or uhci cleanup code (during
EhcExitBootService() or UhcExitBootService() ) might do something crazy
that leaves some of these devices in a state that's unusable by OS X
(and Linux/Windows do a more thorough job of reinitializing them due
to the wider range of crazy hardware and vendors they all have to deal
with).

BTW, I am really grateful to everyone throwning ideas and
brainstorming in my direction. I do understand how frustrating this
can get, debugging a crazy problem only one or two people are even
capable of reproducing... :)

Thanks again,
--Gabriel

On 09/15/14 16:50, Gabriel L. Somlo wrote:
> On Fri, Sep 12, 2014 at 03:59:52PM -0400, Gabriel L. Somlo wrote:
>> On Fri, Sep 12, 2014 at 08:26:01PM +0200, Paolo Bonzini wrote:
>>> So it could be an OVMF bug related to multifunction devices.
>>>
>>> Well, you could try moving devices around in different functions.
>>> You could try moving ehci1 to 0 and the UHCIs to 1/2/7.
>>>
>>> Or drop uhci2/uhci3 and move the two remaining devices around.  Once you
>>> have three combinations that work (e.g. 0/4, 0/6, 0/7) you could use it
>>> to add three UHCI controllers (in the above examples, it would be 0/1/2/7).
>>>
>>> Remember that one of the two must be xx.0, the other can be anything
>>> from xx.1 to xx.7.
>>
>> I moved things around as you suggested (from hw/usb/hcd-ehci-pci.c and
>> the ich9_1d[] array).
>>
>> No matter which PCI function gets assigned to which device, and no
>> matter which order the uhci1/2/3 devices are listed in ich9_1d[],
>> it's *always* uhci3 (dev.id. 2936) and ehci being shown, and uhci1&2
>> end up missing.
>>
>> Interestingly, if I comment out uhci3, it's only ehci that shows up,
>> not uhci1 or uhci2 (even though one of them is 00:1d.0). 
>>
>>
>> Feels like there's some thing "magical" about the uhci3 name or device
>> ID. Maybe at this point I should go fishing in the edk2 source :) 
> 
> Even more interesting, if I use uhci3 for all three uhci devices in
> qemu:
> 
> 
> diff --git a/hw/usb/hcd-ehci-pci.c b/hw/usb/hcd-ehci-pci.c
> index 289ca3b..bb230f1 100644
> --- a/hw/usb/hcd-ehci-pci.c
> +++ b/hw/usb/hcd-ehci-pci.c
> @@ -208,8 +208,8 @@ struct ehci_companions {
>  };
>  
>  static const struct ehci_companions ich9_1d[] = {
> -    { .name = "ich9-usb-uhci1", .func = 0, .port = 0 },
> -    { .name = "ich9-usb-uhci2", .func = 1, .port = 2 },
> +    { .name = "ich9-usb-uhci3", .func = 0, .port = 0 },
> +    { .name = "ich9-usb-uhci3", .func = 1, .port = 2 },
>      { .name = "ich9-usb-uhci3", .func = 2, .port = 4 },
>  };
> 
> 
> they *all* get detected and work great on ovmf+osx. Slow kbd+mouse
> get routed automatically to one of them, and work fine. The only
> differences I can see between them (in hw/usb/hcd-uhci.c) is
> the name string and "irq_pin" field. Not sure yet if that's likely
> to point to an explanation...

It is actually extremely relevant, the irq_pin field. I'm not exactly
sure how just yet, but it is. Maybe check the interrupt routing in OSX
somehow? Do you have a dmesg-like log in OSX, with a PRT dump from the
DSDT, and messages about interrupt routing setup? Do you have in OSX
anything that corresponds to /proc/interrupts under Linux?

Laszlo