From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51814) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XTXml-0005I6-MG for qemu-devel@nongnu.org; Mon, 15 Sep 2014 11:01:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XTXmg-0007Bm-7S for qemu-devel@nongnu.org; Mon, 15 Sep 2014 11:01:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:30069) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XTXmf-0007BM-Vi for qemu-devel@nongnu.org; Mon, 15 Sep 2014 11:01:42 -0400 Message-ID: <5416FF41.7010800@redhat.com> Date: Mon, 15 Sep 2014 17:01:21 +0200 From: Laszlo Ersek MIME-Version: 1.0 References: <20140915145005.GM1825@ERROL.INI.CMU.EDU> In-Reply-To: <20140915145005.GM1825@ERROL.INI.CMU.EDU> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Gabriel L. Somlo" , Paolo Bonzini Cc: agraf@suse.de, reza.jelveh@tuhh.de, edk2-devel@lists.sourceforge.net, Gerd Hoffmann , qemu-devel@nongnu.org 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