From: Laszlo Ersek <lersek@redhat.com>
To: "Gabriel L. Somlo" <gsomlo@gmail.com>,
Paolo Bonzini <pbonzini@redhat.com>
Cc: agraf@suse.de, reza.jelveh@tuhh.de,
edk2-devel@lists.sourceforge.net, qemu-devel@nongnu.org,
kraxel@redhat.com
Subject: Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse
Date: Thu, 11 Sep 2014 22:46:38 +0200 [thread overview]
Message-ID: <54120A2E.80909@redhat.com> (raw)
In-Reply-To: <20140911201638.GF1825@ERROL.INI.CMU.EDU>
On 09/11/14 22:16, Gabriel L. Somlo wrote:
> On Thu, Sep 11, 2014 at 06:40:38PM +0200, Paolo Bonzini wrote:
>> Il 11/09/2014 18:35, Gabriel L. Somlo ha scritto:
>>>>> Can you configure Chamaleon to avoid the boot prompt?
>>> Yes. After doing that, usb starts working once OS X is fully booted.
>>>
>>> Works with either piix or q35 just fine.
>>>
>>> Does this mean it's likely to be an OVMF uhci/ehci issue specific to Q35 ?
>>> (one from which Fedora can recover but OS X can't) ?
>>
>> Yes, that's my interpretation too.
>>
>> You did test an UHCI controller, I think, but I don't remember---did you
>> test an EHCI controller without companions, using something like
>> "-device ich9-usb-ehci1,id=myehci -device usb-keyboard,bus=myehci.0"?
>
> Not only does that work (after applying Jan Vesely's 3-patch series from
> http://lists.nongnu.org/archive/html/qemu-devel/2014-09/msg02175.html),
> but my "regular" command line starts working as well, since now both
> keyboard and mouse get routed to ehci instead of uhci.
>
>> If that works, the issue would be specific to EHCI companion
>> controllers. If that doesn't work, there is at least a generic in the
>> EHCI driver---of course there could possibly be another in the companion
>> controllers, but I'd try getting EHCI alone to work.
>
> So, here's my command line again:
>
> bin/qemu-system-x86_64 -enable-kvm -m 2048 -cpu core2duo -smp 4,cores=2 \
> -machine q35 -device ide-drive,bus=ide.2,drive=MacHDD \
> -drive id=MacHDD,if=none,snapshot=on,file=./mac_10.9.img \
> -device isa-applesmc,osk="our...Inc" \
> -netdev user,id=usr0 -device e1000-82545em,netdev=usr0,id=vnet0 \
> -usb -device usb-kbd -device usb-mouse \
> [ -bios OVMF.fd | -kernel chameleon_boot ]
>
>
> With this, I was able to get a better idea what the problem is. With
> either OVMF or Chameleon, I still see UHCI 1..3 and EHCI in qtree,
> with the mouse and keyboard hanging off of EHCI.
>
> However, from inside the OS X guest's system profiler, I see a
> difference:
>
> With Chameleon (and SeaBIOS), I see all three UHCIs (with no attached
> devices), and EHCI (with the now-high-speed keyboard and mouse).
>
> With OVMF, I have EHCI with the high-speed (and working)
> keyboard+mouse, but ONLY ONE UHCI device (UHCI3). UHCI1 UHCI2 do not
> get detected.
>
> Obviously, since QEMU was routing the slow keyboard+mouse to UHCI1,
> which for some reason gets masked when OVMF is used, things weren't
> working.
>
> So now the question is, how come Fedora can find UHCI 1&2 on Q35+OVMF,
> but OS X can't, and what can we do to OVMF (and/or QEMU) to fix it.
>
> Obviously, Jan's patch set woud paper over the issue, as the keyboard
> and mouse would go to ehci, but there's still the issue of the
> disappearing UHCI's :)
Please save the OVMF debug log, maybe we can catch something in it.
-global isa-debugcon.iobase=0x402 -debugcon file:ovmf.log
It could be also worthwhile to boot OVMF (not OSX, just OVMF) on both
i440fx and q35, with the otherwise same command line, and compare the
two debug logs.
Thanks
Laszlo
next prev parent reply other threads:[~2014-09-11 20:47 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
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 [this message]
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=54120A2E.80909@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=pbonzini@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).