From patchwork Mon Sep 15 14:50:06 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Gabriel L. Somlo" X-Patchwork-Id: 389393 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 02440140078 for ; Tue, 16 Sep 2014 00:51:02 +1000 (EST) Received: from localhost ([::1]:60296 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XTXcK-0000VD-VC for incoming@patchwork.ozlabs.org; Mon, 15 Sep 2014 10:51:00 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48252) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XTXbe-0008S3-7j for qemu-devel@nongnu.org; Mon, 15 Sep 2014 10:50:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XTXbX-0003CB-6q for qemu-devel@nongnu.org; Mon, 15 Sep 2014 10:50:18 -0400 Received: from mail-qg0-x236.google.com ([2607:f8b0:400d:c04::236]:55878) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XTXbX-0003C0-2G for qemu-devel@nongnu.org; Mon, 15 Sep 2014 10:50:11 -0400 Received: by mail-qg0-f54.google.com with SMTP id z60so3888152qgd.41 for ; Mon, 15 Sep 2014 07:50:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=iNRvP9DHeewBU5irudqkZjMmGrWMx789UNhj1ZOI3U0=; b=LV8feg0PGlEFCP/Vwg2ej+UwQ9eZadznrl+Cv020J114VBiIUoF2gmkL43r7aBdRA7 sCddu0lA1NBS4xYJCfiStA8/NMcWDboLAoJX4GK03j1rL315Hr3W39lIOScfcy62hAN5 EGEnxeWngixMrIiLSPU3lFg/9wKepetBA8z9po+71pDZD7IvJgqWC2IL3DmNZ3JROoRr m3K6oCYSDr1mIhn0oa/i9JXskO8VXrlMUVt6sC7dBzmN2VfuooP7kazIb+XliAavEJQ5 tVnmANrin5HI7uH5PBPmP9jbJxK+QYGmrvzeaDkhW3WMA1Kt7cdtxLV6QIv3fwYbrdPh 75IA== X-Received: by 10.224.47.130 with SMTP id n2mr37744347qaf.87.1410792609903; Mon, 15 Sep 2014 07:50:09 -0700 (PDT) Received: from ERROL.INI.CMU.EDU (ERROL.INI.CMU.EDU. [128.2.16.43]) by mx.google.com with ESMTPSA id d3sm9720013qar.42.2014.09.15.07.50.09 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Sep 2014 07:50:09 -0700 (PDT) Date: Mon, 15 Sep 2014 10:50:06 -0400 From: "Gabriel L. Somlo" To: Paolo Bonzini Message-ID: <20140915145005.GM1825@ERROL.INI.CMU.EDU> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20140912195951.GK1825@ERROL.INI.CMU.EDU> User-Agent: Mutt/1.5.23 (2014-03-12) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400d:c04::236 Cc: edk2-devel@lists.sourceforge.net, agraf@suse.de, qemu-devel@nongnu.org, Gerd Hoffmann , reza.jelveh@tuhh.de, lersek@redhat.com Subject: Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org 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 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 }, };