qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>, "Gabriel L. Somlo" <gsomlo@gmail.com>
Cc: agraf@suse.de, edk2-devel@lists.sourceforge.net,
	qemu-devel@nongnu.org, reza.jelveh@tuhh.de
Subject: Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse
Date: Wed, 10 Sep 2014 09:59:27 +0200	[thread overview]
Message-ID: <541004DF.30405@redhat.com> (raw)
In-Reply-To: <1410330668.3389.11.camel@nilsson.home.kraxel.org>

On 09/10/14 08:31, Gerd Hoffmann wrote:
>   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.

Is "4.2.1 Port Routing Control via EHCI Configured (CF) Bit" related?
The Configured Flag (CF) is the global one apparently, and the Port
Owner bit is per port.

In "MdeModulePkg/Bus/Pci/EhciDxe/", the CF flag seems to be called
CONFIGFLAG_ROUTE_EHC, and Port Owner is PORTSC_OWNER.

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

I'm glad I happened to suggest the same. ;)

Laszlo

  reply	other threads:[~2014-09-10  7:59 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-09 22:00 [Qemu-devel] OVMF, Q35 and USB keyboard/mouse Gabriel L. Somlo
2014-09-10  0:40 ` Laszlo Ersek
2014-09-10  6:31 ` Gerd Hoffmann
2014-09-10  7:59   ` Laszlo Ersek [this message]
2014-09-10 14:06     ` Gabriel L. Somlo
2014-09-10 23:08       ` [Qemu-devel] [edk2] " Paolo Bonzini
2014-09-11 15:42         ` [Qemu-devel] " Gabriel L. Somlo
2014-09-11 15:49           ` Paolo Bonzini
2014-09-11 16:35             ` Gabriel L. Somlo
2014-09-11 16:40               ` Paolo Bonzini
2014-09-11 17:11                 ` Gabriel L. Somlo
2014-09-11 17:15                   ` [Qemu-devel] [edk2] " Paolo Bonzini
2014-09-11 20:16                 ` [Qemu-devel] " Gabriel L. Somlo
2014-09-11 20:46                   ` Laszlo Ersek
2014-09-11 21:34                     ` Alexander Graf
2014-09-11 23:21                       ` Gabriel L. Somlo
2014-09-12  9:17                         ` BALATON Zoltan
2014-09-12 17:58                           ` Gabriel L. Somlo
2014-09-12  6:46                   ` Gerd Hoffmann
2014-09-12 18:18                     ` Gabriel L. Somlo
2014-09-12 18:26                       ` Paolo Bonzini
2014-09-12 19:59                         ` Gabriel L. Somlo
2014-09-13  5:06                           ` Laszlo Ersek
2014-09-15 14:50                           ` Gabriel L. Somlo
2014-09-15 15:01                             ` Laszlo Ersek
2014-09-15 15:07                               ` Gabriel L. Somlo
2014-09-15 18:02                                 ` Laszlo Ersek
2014-09-15 19:23                                   ` Gabriel L. Somlo
2014-09-15 19:56                                     ` BALATON Zoltan
2014-09-16  8:15                                     ` Gerd Hoffmann
2014-09-21 20:00                                       ` Gabriel L. Somlo
2014-09-21 22:10                                   ` Gabriel L. Somlo
2014-09-21 22:43                                     ` Laszlo Ersek
2014-09-22 16:44                                       ` [Qemu-devel] [edk2] " Paolo Bonzini
2014-09-22 16:59                                         ` Gabriel L. Somlo
2014-09-22 20:40                                         ` Laszlo Ersek
2014-09-24 22:03                                           ` Gabriel L. Somlo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=541004DF.30405@redhat.com \
    --to=lersek@redhat.com \
    --cc=agraf@suse.de \
    --cc=edk2-devel@lists.sourceforge.net \
    --cc=gsomlo@gmail.com \
    --cc=kraxel@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=reza.jelveh@tuhh.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).