[Qemu-devel] OVMF, Q35 and USB keyboard/mouse

[Qemu-devel] OVMF, Q35 and USB keyboard/mouse

[Gabriel L. Somlo]

Executive summary: OS X (10.9.4) works on Q35 with usb keyboard+mouse when
booted on SeaBIOS with Chameleon , but not on OVMF [1].

[1] Recently patched acpi pm timer to boot on Q35, plus a bunch of pending
    sata patches by Reza, cc-ed.

Command lines used to test using Fedora 20 live and OS X 10.9
(with or without OVMF for Fedora, with OVMF or Chameleon for OS X):

bin/qemu-system-x86_64 -enable-kvm -m 2048 -machine q35 \
  -device ide-drive,bus=ide.2,drive=CD \
  -drive id=CD,if=none,snapshot=on,file=./Fed-Live-Desktop-x86_64-20-1.iso \
  -usb -device usb-kbd -device usb-mouse \
  [ -bios OVMF.fd ]

bin/qemu-system-x86_64 -enable-kvm -m 2048 -cpu core2duo -machine q35 \
  -device isa-applesmc,osk="our...Inc" \
  -netdev user,id=usr0 -device e1000-82545em,netdev=usr0,id=vnet0 \
  -device ide-drive,bus=ide.2,drive=MacHDD \
  -drive id=MacHDD,if=none,snapshot=on,file=./mac_10.9.img \
  -usb -device usb-kbd -device usb-mouse \
  [ -kernel ./chameleon_boot | -bios OVMF.fd ]

In all cases, we get this from "info qtree":

      dev: ich9-usb-uhci3, id ""
        masterbus = "usb-bus.0"
        firstport = 4 (0x4)
        bandwidth = 1280 (0x500)
        maxframes = 128 (0x80)
        addr = 1d.2
        romfile = ""
        rombar = 1 (0x1)
        multifunction = true
        command_serr_enable = true
        class USB controller, addr 00:1d.2, pci id 8086:2936 (sub 1af4:1100)
        bar 4: i/o at 0xc0a0 [0xc0bf]
      dev: ich9-usb-uhci2, id ""
        masterbus = "usb-bus.0"
        firstport = 2 (0x2)
        bandwidth = 1280 (0x500)
        maxframes = 128 (0x80)
        addr = 1d.1
        romfile = ""
        rombar = 1 (0x1)
        multifunction = true
        command_serr_enable = true
        class USB controller, addr 00:1d.1, pci id 8086:2935 (sub 1af4:1100)
        bar 4: i/o at 0xc0c0 [0xc0df]
      dev: ich9-usb-uhci1, id ""
        masterbus = "usb-bus.0"
        firstport = 0 (0x0)
        bandwidth = 1280 (0x500)
        maxframes = 128 (0x80)
        addr = 1d.0
        romfile = ""
        rombar = 1 (0x1)
        multifunction = true
        command_serr_enable = true
        class USB controller, addr 00:1d.0, pci id 8086:2934 (sub 1af4:1100)
        bar 4: i/o at 0xc0e0 [0xc0ff]
      dev: ich9-usb-ehci1, id ""
        maxframes = 128 (0x80)
        addr = 1d.7
        romfile = ""
        rombar = 1 (0x1)
        multifunction = true
        command_serr_enable = true
        class USB controller, addr 00:1d.7, pci id 8086:293a (sub 1af4:1100)
        bar 0: mem at 0x82021000 [0x82021fff]
        bus: usb-bus.0
          type usb-bus
          dev: usb-mouse, id ""
            port = ""
            serial = ""
            full-path = true
            msos-desc = true
            addr 0.2, port 2, speed 12, name QEMU USB Mouse, attached
          dev: usb-kbd, id ""
            display = ""
            port = ""
            serial = ""
            full-path = true
            msos-desc = true
            addr 0.1, port 1, speed 12, name QEMU USB Keyboard, attached


In all *working* cases (all except OSX+OVMF) the guest os (mac or linux)
reports the keyboard and mouse as connected to ich9-usb-uhci1 (dev. id 0x2934),
contradicting the qtree output. On linux I got this out of 'dmesg':

input: QEMU QEMU USB Keyboard as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0/input/input3
hid-generic 0003:0627:0001.0001: input,hidraw0: USB HID v1.11 Keyboard [QEMU QEMU USB Keyboard] on usb-0000:00:1d.0-1/input0
input: QEMU QEMU USB Mouse as /devices/pci0000:00/0000:00:1d.0/usb2/2-2/2-2:1.0/input/input4
hid-generic 0003:0627:0001.0002: input,hidraw1: USB HID v0.01 Mouse [QEMU QEMU USB Mouse] on usb-0000:00:1d.0-2/input0

On OS X (with Chameleon), I get the same results using System Profiler.


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 ?


BTW, doing something like:

  -usb -device ich9-usb-uhci1,id=uhci1 -device usb-kbd,bus=uhci1.0 \
       -device ich9-usb-uhci2,id=uhci2 -device usb-mouse,bus=uhci2.0

to completely override uhci1 and uhci2, and force the keyboard and mouse
to connect there causes OS X to start working on OVMF.


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).


Any thoughts or comments (or tips for further debugging) much appreciated.

Thanks,
--Gabriel

Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse

[Laszlo Ersek]

On 09/10/14 00:00, Gabriel L. Somlo wrote:
> Executive summary: OS X (10.9.4) works on Q35 with usb keyboard+mouse when
> booted on SeaBIOS with Chameleon , but not on OVMF [1].
> 
> [1] Recently patched acpi pm timer to boot on Q35, plus a bunch of pending
>     sata patches by Reza, cc-ed.
> 
> Command lines used to test using Fedora 20 live and OS X 10.9
> (with or without OVMF for Fedora, with OVMF or Chameleon for OS X):
> 
> bin/qemu-system-x86_64 -enable-kvm -m 2048 -machine q35 \
>   -device ide-drive,bus=ide.2,drive=CD \
>   -drive id=CD,if=none,snapshot=on,file=./Fed-Live-Desktop-x86_64-20-1.iso \
>   -usb -device usb-kbd -device usb-mouse \
>   [ -bios OVMF.fd ]
> 
> bin/qemu-system-x86_64 -enable-kvm -m 2048 -cpu core2duo -machine q35 \
>   -device isa-applesmc,osk="our...Inc" \
>   -netdev user,id=usr0 -device e1000-82545em,netdev=usr0,id=vnet0 \
>   -device ide-drive,bus=ide.2,drive=MacHDD \
>   -drive id=MacHDD,if=none,snapshot=on,file=./mac_10.9.img \
>   -usb -device usb-kbd -device usb-mouse \
>   [ -kernel ./chameleon_boot | -bios OVMF.fd ]
> 
> In all cases, we get this from "info qtree":
> 
>       dev: ich9-usb-uhci3, id ""
>         masterbus = "usb-bus.0"
>         firstport = 4 (0x4)
>         bandwidth = 1280 (0x500)
>         maxframes = 128 (0x80)
>         addr = 1d.2
>         romfile = ""
>         rombar = 1 (0x1)
>         multifunction = true
>         command_serr_enable = true
>         class USB controller, addr 00:1d.2, pci id 8086:2936 (sub 1af4:1100)
>         bar 4: i/o at 0xc0a0 [0xc0bf]
>       dev: ich9-usb-uhci2, id ""
>         masterbus = "usb-bus.0"
>         firstport = 2 (0x2)
>         bandwidth = 1280 (0x500)
>         maxframes = 128 (0x80)
>         addr = 1d.1
>         romfile = ""
>         rombar = 1 (0x1)
>         multifunction = true
>         command_serr_enable = true
>         class USB controller, addr 00:1d.1, pci id 8086:2935 (sub 1af4:1100)
>         bar 4: i/o at 0xc0c0 [0xc0df]
>       dev: ich9-usb-uhci1, id ""
>         masterbus = "usb-bus.0"
>         firstport = 0 (0x0)
>         bandwidth = 1280 (0x500)
>         maxframes = 128 (0x80)
>         addr = 1d.0
>         romfile = ""
>         rombar = 1 (0x1)
>         multifunction = true
>         command_serr_enable = true
>         class USB controller, addr 00:1d.0, pci id 8086:2934 (sub 1af4:1100)
>         bar 4: i/o at 0xc0e0 [0xc0ff]
>       dev: ich9-usb-ehci1, id ""
>         maxframes = 128 (0x80)
>         addr = 1d.7
>         romfile = ""
>         rombar = 1 (0x1)
>         multifunction = true
>         command_serr_enable = true
>         class USB controller, addr 00:1d.7, pci id 8086:293a (sub 1af4:1100)
>         bar 0: mem at 0x82021000 [0x82021fff]
>         bus: usb-bus.0
>           type usb-bus
>           dev: usb-mouse, id ""
>             port = ""
>             serial = ""
>             full-path = true
>             msos-desc = true
>             addr 0.2, port 2, speed 12, name QEMU USB Mouse, attached
>           dev: usb-kbd, id ""
>             display = ""
>             port = ""
>             serial = ""
>             full-path = true
>             msos-desc = true
>             addr 0.1, port 1, speed 12, name QEMU USB Keyboard, attached
> 
> 
> In all *working* cases (all except OSX+OVMF) the guest os (mac or linux)
> reports the keyboard and mouse as connected to ich9-usb-uhci1 (dev. id 0x2934),
> contradicting the qtree output. On linux I got this out of 'dmesg':
> 
> input: QEMU QEMU USB Keyboard as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0/input/input3
> hid-generic 0003:0627:0001.0001: input,hidraw0: USB HID v1.11 Keyboard [QEMU QEMU USB Keyboard] on usb-0000:00:1d.0-1/input0
> input: QEMU QEMU USB Mouse as /devices/pci0000:00/0000:00:1d.0/usb2/2-2/2-2:1.0/input/input4
> hid-generic 0003:0627:0001.0002: input,hidraw1: USB HID v0.01 Mouse [QEMU QEMU USB Mouse] on usb-0000:00:1d.0-2/input0
> 
> On OS X (with Chameleon), I get the same results using System Profiler.
> 
> 
> 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 ?
> 
> 
> BTW, doing something like:
> 
>   -usb -device ich9-usb-uhci1,id=uhci1 -device usb-kbd,bus=uhci1.0 \
>        -device ich9-usb-uhci2,id=uhci2 -device usb-mouse,bus=uhci2.0
> 
> to completely override uhci1 and uhci2, and force the keyboard and mouse
> to connect there causes OS X to start working on OVMF.
> 
> 
> 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).
> 
> 
> Any thoughts or comments (or tips for further debugging) much appreciated.

My take is that "MdeModulePkg/Bus/Pci/EhciDxe" does something to the
devices that trips up OSX, but doesn't trip up Linux. Try building OVMF
without this driver, and see what happens.

The following (in the driver's INF file) could be relevant:

#  Note that EhciDxe driver is enhanced to guarantee that the EHCI
#  controller get attached to the EHCI controller before the UHCI driver
#  attaches to the companion UHCI controller.  This way avoids the
#  control transfer on a shared port between EHCI and companion host
#  controller when UHCI gets attached earlier than EHCI and a USB 2.0
#  device inserts.

I think that the qtree output is correct, and the working cases work
because the guests can somehow "downgrade" the devices from 2.0 to 1.1
(or maybe 1.0, no clue). Ie. the mouse / tablet is plugged in a shared
port, and after some fiddling, UHCI wins (in the working cases). OVMF's
EHCI driver probably leaves things in such a state that OSX chokes on them.

Apologies if I just wrote a load of BS. :)

Laszlo

Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse

[Gerd Hoffmann]

  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.

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?

cheers,
  Gerd

Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse

[Laszlo Ersek]

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

Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse

[Gabriel L. Somlo]

Hi Gerd & Laszlo,

On Wed, Sep 10, 2014 at 09:59:27AM +0200, Laszlo Ersek wrote:
> On 09/10/14 08:31, Gerd Hoffmann wrote:
> > 
> > What happens if you build ovmf with uhci but without ehci driver?  Does
> > that work?
> 
> I'm glad I happened to suggest the same. ;)

Commenting out MdeModulePkg/Bus/Pci/EhciDxe/EhciDxe.inf from
OvmfPkgX64.[dsc,fdf] doesn't change anything, I still get no mouse
movement and "usb-kbd: warning: key event queue full" after a few
keypresses.
 
> >> 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.

If it's in QEMU, it's only tickled by the OVMF + OSX combination.
Fedora works (around it) fine, and everyone's happy when using
SeaBIOS (and Chameleon, in OSX's case).

BTW, when I do something like this:

-usb -device ich9-usb-uhci1,id=uhci1 -device usb-kbd,bus=uhci1.0 \
     -device ich9-usb-uhci2,id=uhci2 -device usb-mouse,bus=uhci2.0

I get an additional pair of uhci1 and uhci2 devices in qtree (at PCI
00:03.0 and 00:04.0, respectively). OS X "System Information" shows
these two instead of the default uhci[1,2] (which are still shown
in qtree at pci 00:1d.0 and 00:1d.1); It shows the default uhci3 at
pci 00:1d.2, and the default ehci.

With this configuration, keyboard and mouse work just fine on OSX+OVMF.
Not sure, but hoping this provides some useful information to you.

I'm still poring over the rest of the stuff you said, which is a
slightly slower process :)

Thanks much,
--Gabriel

Re: [Qemu-devel] [edk2] OVMF, Q35 and USB keyboard/mouse

[Paolo Bonzini]

Il 10/09/2014 16:06, Gabriel L. Somlo ha scritto:
> If it's in QEMU, it's only tickled by the OVMF + OSX combination.
> Fedora works (around it) fine, and everyone's happy when using
> SeaBIOS (and Chameleon, in OSX's case).
> 
> BTW, when I do something like this:
> 
> -usb -device ich9-usb-uhci1,id=uhci1 -device usb-kbd,bus=uhci1.0 \
>      -device ich9-usb-uhci2,id=uhci2 -device usb-mouse,bus=uhci2.0
> 
> I get an additional pair of uhci1 and uhci2 devices in qtree (at PCI
> 00:03.0 and 00:04.0, respectively). OS X "System Information" shows
> these two instead of the default uhci[1,2] (which are still shown
> in qtree at pci 00:1d.0 and 00:1d.1); It shows the default uhci3 at
> pci 00:1d.2, and the default ehci.
> 
> With this configuration, keyboard and mouse work just fine on OSX+OVMF.
> Not sure, but hoping this provides some useful information to you.
> 
> I'm still poring over the rest of the stuff you said, which is a
> slightly slower process :)

Could you try building a SeaBIOS without EHCI and UHCI support, and see
if it also triggers the bug?

Paolo

Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse

[Gabriel L. Somlo]

On Thu, 11 Sep 2014 01:08:39 +0200, Paolo Bonzini wrote:
> Il 10/09/2014 16:06, Gabriel L. Somlo ha scritto:
> > If it's in QEMU, it's only tickled by the OVMF + OSX combination.
> > Fedora works (around it) fine, and everyone's happy when using
> > SeaBIOS (and Chameleon, in OSX's case).
> > 
> > BTW, when I do something like this:
> > 
> > -usb -device ich9-usb-uhci1,id=uhci1 -device usb-kbd,bus=uhci1.0 \
> >      -device ich9-usb-uhci2,id=uhci2 -device usb-mouse,bus=uhci2.0
> > 
> > I get an additional pair of uhci1 and uhci2 devices in qtree (at PCI
> > 00:03.0 and 00:04.0, respectively). OS X "System Information" shows
> > these two instead of the default uhci[1,2] (which are still shown
> > in qtree at pci 00:1d.0 and 00:1d.1); It shows the default uhci3 at
> > pci 00:1d.2, and the default ehci.
> > 
> > With this configuration, keyboard and mouse work just fine on OSX+OVMF.
> > Not sure, but hoping this provides some useful information to you.
> > 
> > I'm still poring over the rest of the stuff you said, which is a
> > slightly slower process :)
> 
> Could you try building a SeaBIOS without EHCI and UHCI support, and see
> if it also triggers the bug?

Building SeaBIOS w/o EHCI and UHCI won't allow me to type into
Chameleon's boot prompt at all (and yes, I do end up getting the
"usb-kbd: warning: key event queue full" errors after a few
keystrokes).

So it *looks* similar, but happens everywhere (q35 or piix, fedora
or osx, etc.)

The problem I'm encountering only occurs with (Q35 & OVMF & OSX).
Replace either component, e.g. (* & * & Fedora), or (* & Seabios & *),
or (PIIX & * & *) and things work just fine... :)

Thanks,
--Gabriel

Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse

[Paolo Bonzini]

Il 11/09/2014 17:42, Gabriel L. Somlo ha scritto:
> Building SeaBIOS w/o EHCI and UHCI won't allow me to type into
> Chameleon's boot prompt at all (and yes, I do end up getting the
> "usb-kbd: warning: key event queue full" errors after a few
> keystrokes).

Can you configure Chamaleon to avoid the boot prompt?

Paolo

> So it *looks* similar, but happens everywhere (q35 or piix, fedora
> or osx, etc.)
> 
> The problem I'm encountering only occurs with (Q35 & OVMF & OSX).
> Replace either component, e.g. (* & * & Fedora), or (* & Seabios & *),
> or (PIIX & * & *) and things work just fine... :)

Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse

[Gabriel L. Somlo]

On Thu, Sep 11, 2014 at 05:49:08PM +0200, Paolo Bonzini wrote:
> Il 11/09/2014 17:42, Gabriel L. Somlo ha scritto:
> > Building SeaBIOS w/o EHCI and UHCI won't allow me to type into
> > Chameleon's boot prompt at all (and yes, I do end up getting the
> > "usb-kbd: warning: key event queue full" errors after a few
> > keystrokes).
> 
> 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) ? 

Thanks,
--Gabriel

> > So it *looks* similar, but happens everywhere (q35 or piix, fedora
> > or osx, etc.)
> > 
> > The problem I'm encountering only occurs with (Q35 & OVMF & OSX).
> > Replace either component, e.g. (* & * & Fedora), or (* & Seabios & *),
> > or (PIIX & * & *) and things work just fine... :)
> 

Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse

[Paolo Bonzini]

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

Paolo

Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse

[Gabriel L. Somlo]

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

That fails during QEMU initialization with:

qemu-system-x86_64: -device usb-kbd,bus=myehci.0: Warning:
speed mismatch trying to attach usb device "QEMU USB Keyboard" (full
speed) to bus "myehci.0", port "1" (high speed)
qemu-system-x86_64: -device usb-kbd,bus=myehci.0: Device
initialization failed.
qemu-system-x86_64: -device usb-kbd,bus=myehci.0: Device 'usb-kbd'
could not be initialized

So I guess OVMF doesn't have a chance to get involved here before we
crash and burn :)

Thanks,
--Gabriel

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

Re: [Qemu-devel] [edk2] OVMF, Q35 and USB keyboard/mouse

[Paolo Bonzini]

Il 11/09/2014 19:11, Gabriel L. Somlo ha scritto:
> 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"?
> 
> That fails during QEMU initialization with:
> 
> qemu-system-x86_64: -device usb-kbd,bus=myehci.0: Warning:
> speed mismatch trying to attach usb device "QEMU USB Keyboard" (full
> speed) to bus "myehci.0", port "1" (high speed)
> qemu-system-x86_64: -device usb-kbd,bus=myehci.0: Device
> initialization failed.
> qemu-system-x86_64: -device usb-kbd,bus=myehci.0: Device 'usb-kbd'
> could not be initialized
> 
> So I guess OVMF doesn't have a chance to get involved here before we
> crash and burn :)

Ah, that needs this patch here:

http://article.gmane.org/gmane.comp.emulators.qemu/296216/raw

Paolo

> Thanks,
> --Gabriel
> 
>> 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.
> 
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> 

Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse

[Gabriel L. Somlo]

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 :)

Thanks much,
--Gabriel

Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse

[Laszlo Ersek]

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

Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse

[Alexander Graf]

> Am 11.09.2014 um 22:46 schrieb Laszlo Ersek <lersek@redhat.com>:
> 
>> 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.

XNU also populates its device tree based on the DSDT. Maybe there's a subtle difference there?

Alex

> 
> Thanks
> Laszlo

Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse

[Gabriel L. Somlo]

On Thu, Sep 11, 2014 at 11:34:03PM +0200, Alexander Graf wrote:
> >> 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 :)
> > 
> 
> XNU also populates its device tree based on the DSDT. Maybe there's a
> subtle difference there?

This was the low hanging fruit, so I checked it first :) Pulled the
DSDT using the OS X version of "DSDTEditor" (found on insanelymac)
on both the Chameleon q35 version which had all three UHCIs and from
the OVMF q35 version which only showed UHCI3. The two DSDTs looked
absolutely identical (no output from diff)...

Thanks,
--Gabriel

Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse

[Gerd Hoffmann]

 Hi,

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

Now *that* is really strange, especially as UHCI1 is pci function 0,
without probing that successfully you wouldn't see the other pci
functions (1+2+7 for uhci2+uhci3+ehci) in the same slot in the first
place.

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

Try '-device usb-mouse,port=5 -device usb-kbd,port=6'.  That links mouse
+kbd to the ports which are routed to uhci3.  Which of course also only
papers over the root cause.  But should do as workaround for the time
being and is also a useful data point.

cheers,
  Gerd

Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse

[BALATON Zoltan]

On Thu, 11 Sep 2014, Gabriel L. Somlo wrote:
> On Thu, Sep 11, 2014 at 11:34:03PM +0200, Alexander Graf wrote:
>> XNU also populates its device tree based on the DSDT. Maybe there's a
>> subtle difference there?
>
> This was the low hanging fruit, so I checked it first :) Pulled the
> DSDT using the OS X version of "DSDTEditor" (found on insanelymac)
> on both the Chameleon q35 version which had all three UHCIs and from
> the OVMF q35 version which only showed UHCI3. The two DSDTs looked
> absolutely identical (no output from diff)...

You may also look for differences in USB devices in the ouput of ioreg. 
Maybe that shows something. (It's basically what you can see in System 
Profiler but easier to compare with diff and may have additional data.)

Regards,
BALATON Zoltan

Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse

[Gabriel L. Somlo]

On Fri, Sep 12, 2014 at 11:17:35AM +0200, BALATON Zoltan wrote:
> On Thu, 11 Sep 2014, Gabriel L. Somlo wrote:
> >On Thu, Sep 11, 2014 at 11:34:03PM +0200, Alexander Graf wrote:
> >>XNU also populates its device tree based on the DSDT. Maybe there's a
> >>subtle difference there?
> >
> >This was the low hanging fruit, so I checked it first :) Pulled the
> >DSDT using the OS X version of "DSDTEditor" (found on insanelymac)
> >on both the Chameleon q35 version which had all three UHCIs and from
> >the OVMF q35 version which only showed UHCI3. The two DSDTs looked
> >absolutely identical (no output from diff)...
> 
> You may also look for differences in USB devices in the ouput of ioreg.
> Maybe that shows something. (It's basically what you can see in System
> Profiler but easier to compare with diff and may have additional data.)

Other than lots of off-by-a-few key values, the main two hunks of the
diff between the Chameleon and OVMF instances of a Q35 OSX guest are
simply the missing two "AppleUSBUHCI" arrays:

-	<key>IORegistryEntryChildren</key>
-	<array>
-		<dict>
-			<key>CFBundleIdentifier</key>
-			<string>com.apple.driver.AppleUSBUHCI</string>
-			<key>Card Type</key>
-			<string>PCI</string>
-			<key>Companion</key>
-			<string>yes</string>
-			<key>Errata</key>
-			<integer>0</integer>
-			<key>IOClass</key>
-			<string>AppleUSBUHCI</string>
-			<key>IOMatchCategory</key>
-			<string>IODefaultMatchCategory</string>
-			<key>IOObjectClass</key>
-			<string>AppleUSBUHCI</string>
-			<key>IOObjectRetainCount</key>
-			<integer>11</integer>
-			<key>IOPCIClassMatch</key>
-			<string>0x0C030000</string>
-			<key>IOPowerManagement</key>
-			<dict>
-				<key>ChildrenPowerState</key>
-				<integer>3</integer>
-				<key>CurrentPowerState</key>
-				<integer>3</integer>
-				<key>DevicePowerState</key>
-				<integer>3</integer>
-				<key>DriverPowerState</key>
-				<integer>3</integer>
-				<key>MaxPowerState</key>
-				<integer>4</integer>
-			</dict>
-			<key>IOProbeScore</key>
-			<integer>0</integer>
-			<key>IOProviderClass</key>
-			<string>IOPCIDevice</string>
-			<key>IORegistryEntryChildren</key>
-			<array>
-				<dict>
-					<key>AAPL,current-extra-in-sleep</key>
-					<integer>500</integer>
... etc.

Together, the ioreg xml output files are 50K lines, so I figured I'd
try to spare everyone the pain (but I do have them and can attach them
in private mail in case you think they're worth a second look).

Thanks,
--Gabriel

Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse

[Gabriel L. Somlo]

Hi Gerd,

On Fri, Sep 12, 2014 at 08:46:19AM +0200, Gerd Hoffmann wrote:
> > 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.
> 
> Try '-device usb-mouse,port=5 -device usb-kbd,port=6'.  That links mouse
> +kbd to the ports which are routed to uhci3.  Which of course also only
> papers over the root cause.  But should do as workaround for the time
> being and is also a useful data point.

That works as well (without Jan's high-speed mouse/kbd patch). The
slow mouse+keyboard do indeed end up hanging off of uhci3, which is
the only one visible to OSX, and things work great (while still
leaving uhci1 and 2 somehow "hidden").

> > 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.
> 
> Now *that* is really strange, especially as UHCI1 is pci function 0,
> without probing that successfully you wouldn't see the other pci
> functions (1+2+7 for uhci2+uhci3+ehci) in the same slot in the first
> place.

I've only ever skimmed through the PCI spec at high speed, and have no
real clue about USB, but one thing I noticed is that by default, the
q35 uhci1-3 and ehci1 devices all share the same pci device (1d).

If I explicitly create "-device ich9-usb-ehci1" and
"-device ich9-usb-ehci1" via the command line, they each get their own
distinct PCI device number, and hanging mice and keyboards off of them
works in that case.

Feel free to ignore me because I'm likely wrong, but any chance there
might be some bug related to how all these share a pci device number in
the default setup ?

Thanks,
--Gabriel

Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse

[Paolo Bonzini]

Il 12/09/2014 20:18, Gabriel L. Somlo ha scritto:
>> > Now *that* is really strange, especially as UHCI1 is pci function 0,
>> > without probing that successfully you wouldn't see the other pci
>> > functions (1+2+7 for uhci2+uhci3+ehci) in the same slot in the first
>> > place.
> I've only ever skimmed through the PCI spec at high speed, and have no
> real clue about USB, but one thing I noticed is that by default, the
> q35 uhci1-3 and ehci1 devices all share the same pci device (1d).
> 
> If I explicitly create "-device ich9-usb-ehci1" and
> "-device ich9-usb-ehci1" via the command line, they each get their own
> distinct PCI device number, and hanging mice and keyboards off of them
> works in that case.
> 
> Feel free to ignore me because I'm likely wrong, but any chance there
> might be some bug related to how all these share a pci device number in
> the default setup ?

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.

Paolo

Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse

[Gabriel L. Somlo]

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.

System Information looks like this (high-speed kbd/mouse patch is
applied, so I'm looking for whether uhci2/3 show up in the list or
not, but wanted to always have mouse and keyboard available on ehci):

    USB Device Tree:

--->USB Bus<---
  v USB Hi-Speed Bus
       QEMU USB Keyboard
       QEMU USB Mouse


    USB Bus:

    Host Controller Location: Expansion Slot
    Host Controller Driver:   AppleUSBUHCI
    PCI Device ID:            0x2936
    PCI Revision ID:          0x0003
    PCI Vendor ID:            0x8086
    Bus Number:               0x5d

The bus number varies (depending on which function I hard-coded for
uhci3, e.g. 3d when I had it at 00:1d.1, 5d for the default 00:1d.2,
etc.) but it's always uhci3...


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 :) 

Thanks,
--Gabriel

Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse

[Laszlo Ersek]

On 09/12/14 21:59, 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.
> 
> System Information looks like this (high-speed kbd/mouse patch is
> applied, so I'm looking for whether uhci2/3 show up in the list or
> not, but wanted to always have mouse and keyboard available on ehci):
> 
>     USB Device Tree:
> 
> --->USB Bus<---
>   v USB Hi-Speed Bus
>        QEMU USB Keyboard
>        QEMU USB Mouse
> 
> 
>     USB Bus:
> 
>     Host Controller Location: Expansion Slot
>     Host Controller Driver:   AppleUSBUHCI
>     PCI Device ID:            0x2936
>     PCI Revision ID:          0x0003
>     PCI Vendor ID:            0x8086
>     Bus Number:               0x5d
> 
> The bus number varies (depending on which function I hard-coded for
> uhci3, e.g. 3d when I had it at 00:1d.1, 5d for the default 00:1d.2,
> etc.) but it's always uhci3...
> 
> 
> 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 :) 

Right, a bit earlier I thought of devids being special maybe and grepped
edk2 for "2936" -- no luck. There are hits but they all seem unrelated.

Laszlo

Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse

[Gabriel L. Somlo]

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

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

Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse

[Laszlo Ersek]

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

Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse

[Gabriel L. Somlo]

On Mon, Sep 15, 2014 at 05:01:21PM +0200, Laszlo Ersek wrote:
> > 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?

Actually, even more exciting:

diff --git a/hw/usb/hcd-uhci.c b/hw/usb/hcd-uhci.c
index 3b3ebcd..d61656e 100644
--- a/hw/usb/hcd-uhci.c
+++ b/hw/usb/hcd-uhci.c
@@ -1335,21 +1335,21 @@ static UHCIInfo uhci_info[] = {
         .vendor_id = PCI_VENDOR_ID_INTEL,
         .device_id = PCI_DEVICE_ID_INTEL_82801I_UHCI1,
         .revision  = 0x03,
-        .irq_pin   = 0,
+        .irq_pin   = 1,
         .unplug    = false,
     },{
         .name      = "ich9-usb-uhci2", /* 00:1d.1 */
         .vendor_id = PCI_VENDOR_ID_INTEL,
         .device_id = PCI_DEVICE_ID_INTEL_82801I_UHCI2,
         .revision  = 0x03,
-        .irq_pin   = 1,
+        .irq_pin   = 2,
         .unplug    = false,
     },{
         .name      = "ich9-usb-uhci3", /* 00:1d.2 */
         .vendor_id = PCI_VENDOR_ID_INTEL,
         .device_id = PCI_DEVICE_ID_INTEL_82801I_UHCI3,
         .revision  = 0x03,
-        .irq_pin   = 2,
+        .irq_pin   = 3,
         .unplug    = false,
     },{
         .name      = "ich9-usb-uhci4", /* 00:1a.0 */

Turns out, anything with an irq_pin <= 1 won't show up when osx is
booted on q35 with ovmf (but osx + q35 works if booted via Chameleon).

DSDT looks identical across the ovmf vs. chameleon divide. I'm going
to take some time to do a more thorough search of any and all logging
I can find on OS X, and also try to find wherever in ovmf the guest
device irq pin comes into play where uhci is concerned.

I am basically just poking at it with a stick right now, but maybe
something will start making sense soon :)

Thanks again,
--Gabriel

Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse

[Laszlo Ersek]

On 09/15/14 17:07, Gabriel L. Somlo wrote:
> On Mon, Sep 15, 2014 at 05:01:21PM +0200, Laszlo Ersek wrote:
>>> 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?
> 
> Actually, even more exciting:
> 
> diff --git a/hw/usb/hcd-uhci.c b/hw/usb/hcd-uhci.c
> index 3b3ebcd..d61656e 100644
> --- a/hw/usb/hcd-uhci.c
> +++ b/hw/usb/hcd-uhci.c
> @@ -1335,21 +1335,21 @@ static UHCIInfo uhci_info[] = {
>          .vendor_id = PCI_VENDOR_ID_INTEL,
>          .device_id = PCI_DEVICE_ID_INTEL_82801I_UHCI1,
>          .revision  = 0x03,
> -        .irq_pin   = 0,
> +        .irq_pin   = 1,
>          .unplug    = false,
>      },{
>          .name      = "ich9-usb-uhci2", /* 00:1d.1 */
>          .vendor_id = PCI_VENDOR_ID_INTEL,
>          .device_id = PCI_DEVICE_ID_INTEL_82801I_UHCI2,
>          .revision  = 0x03,
> -        .irq_pin   = 1,
> +        .irq_pin   = 2,
>          .unplug    = false,
>      },{
>          .name      = "ich9-usb-uhci3", /* 00:1d.2 */
>          .vendor_id = PCI_VENDOR_ID_INTEL,
>          .device_id = PCI_DEVICE_ID_INTEL_82801I_UHCI3,
>          .revision  = 0x03,
> -        .irq_pin   = 2,
> +        .irq_pin   = 3,
>          .unplug    = false,
>      },{
>          .name      = "ich9-usb-uhci4", /* 00:1a.0 */
> 
> Turns out, anything with an irq_pin <= 1 won't show up when osx is
> booted on q35 with ovmf (but osx + q35 works if booted via Chameleon).
> 
> DSDT looks identical across the ovmf vs. chameleon divide.

Now I'm curious. What's this chameleon thing? (Yes, I did find the
homepage. Apparently the lead developer is a fellow Hungarian. A small
world.) I'm surprised how you can get the same DSDT under both OVMF and
chameleon. Assuming you run a recent OVMF on a recent QEMU, the DSDT
exposed to the guest will originate from QEMU. This is confirmed by your
q35.log that you sent me in private (due to its size) previously:

InstallQemuLinkedTables: "etc/acpi/tables" offset 0x0000000000000000: Signature="FACS" Length=0x00000040
InstallQemuLinkedTables: "etc/acpi/tables" offset 0x0000000000000040: Signature="DSDT" Length=0x00001CE5
InstallQemuLinkedTables: "etc/acpi/tables" offset 0x0000000000001D25: Signature="FACP" Length=0x00000074
InstallQemuLinkedTables: "etc/acpi/tables" offset 0x0000000000001D99: Signature="SSDT" Length=0x00000687
InstallQemuLinkedTables: "etc/acpi/tables" offset 0x0000000000002420: Signature="APIC" Length=0x00000090
InstallQemuLinkedTables: "etc/acpi/tables" offset 0x00000000000024B0: Signature="HPET" Length=0x00000038
InstallQemuLinkedTables: "etc/acpi/tables" offset 0x00000000000024E8: Signature="QEMU" Length=0x0000003C
InstallQemuLinkedTables: "etc/acpi/tables" offset 0x0000000000002524: Signature="RSDT" Length=0x00000038
InstallAllQemuLinkedTables: installed 7 tables

I've got no clue how you can end up with the exact same DSDT under
chameleon, unless it has a client for QEMU's fw_cfg ACPI linker/loader.

In fact I think that should be *precisely* the difference here. The PCI
interrupt routing table (_PRT) in the DSDT describes a two-level
mapping. (I've probably forgotten most of the details, sorry.) First, it
maps each PCI (bus, dev, pin) triplet to a PNP0C0F ("PCI interrupt
link") device. We usually call these LNKA, LNKB, LNC, LNKD, LNKS on
i440fx; there are more on q35. Then, each LNKx specifies a set of
possible legacy interrupts that the link can be programmed for /
assigned to. At runtime, the OS programs each of the interrupt links to
one of its allowed legacy interrupts, and then all the pins (across
buses and functions) that are connected to that interrupt link will
trigger that interrupt. The OS usually tries to come up with a mapping
(from LNKx to IRQ) so that interrupt sharing is minimized.

Here's an example from my i440fx Fedora 20 VM.

(1) The dmesg says first

  ACPI: PCI Interrupt Link [LNKA] (IRQs 5 10 *11)
  ACPI: PCI Interrupt Link [LNKB] (IRQs 5 10 *11)
  ACPI: PCI Interrupt Link [LNKC] (IRQs 5 *10 11)
  ACPI: PCI Interrupt Link [LNKD] (IRQs 5 *10 11)
  ACPI: PCI Interrupt Link [LNKS] (IRQs *9)

This displays what IRQs the _PRT in the DSDT allows for each of the LNKx
links, and the asterisks show (IIRC) what elements of those sets are
selected (programmed) when Linux inherits the hardware.

(2) Later it logs

  ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 10
  ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11
  ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
  ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10

Let's call this mapping LNK_IRQ().

(3) Then look for the uchi controllers:

  uhci_hcd 0000:00:07.0: irq 10, io base 0x0000c0c0
  uhci_hcd 0000:00:07.1: irq 11, io base 0x0000c0a0
  uhci_hcd 0000:00:07.2: irq 11, io base 0x0000c080

And /proc/interrupts is consistent with that:

             CPU0       CPU1       
   10:          6         25   IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb2
   11:          0          0   IO-APIC-fasteoi   uhci_hcd:usb3, uhci_hcd:usb4, virtio2

These last two blocks are *results*.

Again, this is the result of composing two functions:

  device_interrupt = LNK_IRQ(PRT(bus, dev, pin))

PRT() comes from the DSDT, and maps (bus, dev, pin) to a link, while
LNK_IRQ() comes from the OS (the actual link -> IRQ assignment), and is
restricted to the possibilities offered in the DSDT.

The PRT that QEMU generates follows a rotating pattern (it is not
restricted by physical circuits). As you go from one PCI device to the
next, the same LNKA - LNKD links are distributed over the device's pins,
but the sequence is shifted by one. The idea is that most PCI devices
use only their first pin (INTA), and placing such devices "beside" each
other should nicely iterate over all links, evenly.

Thus far I didn't speak about functions of the same PCI device. I didn't
do that because I'm uneducated (even more than in the above :)). The
basic idea is that different functions of the device will use different
pins. Most devices are single-function, hence they usually stick with
INTA. If you've got a multifunction device, then the functions will use
separate pins.

For example, if I dump and decompile the DSDT in the guest, for bus 0
device 7, I get, from the PRT:

  Package (0x04) { 0x0007FFFF,  Zero,  LNKC,  Zero },  <-- pin 0 / INTA
  Package (0x04) { 0x0007FFFF,  One,  LNKD,  Zero },   <-- pin 1 / INTB
  Package (0x04) { 0x0007FFFF,  0x02,  LNKA,  Zero },  <-- pin 2 / INTC
  Package (0x04) { 0x0007FFFF,  0x03,  LNKB,  Zero },  <-- pin 3 / INTD

Let's put it all together, for a QEMU command line with

  -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x7
  -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x7.0x1
  -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x7.0x2

dev & func,  pin, set  interrupt link  IRQ programmed
set on qemu  in qemu   for dev & pin,  by Linux for
cmdline      source    set in DSDT     link
-----------  --------  --------------  --------------
07.0                0            LNKC              10
07.1                1            LNKD              11
07.2                2            LNKA              11

The first two columns are input parameters (from the command line and
from the source code). The third colum is the result of evaluating PRT()
on the input params. The fourth column is the result of evaluating
Linux's LNK_IRQ() function on the third column.

(Note that all of the above is for i440fx, not q35, but the method is
similar.)

Ultimately, I think that the difference between OVMF and chameleon is
the following: when booting OSX with chameleon, QEMU's rotating _PRT is
not exposed to OSX, because chameleon doesn't know how to download and
interpret the necessary fw_cfg blobs. (What _PRT OSX decides to use
then, I can't imagine.) But when you boot OSX with OVMF, then QEMU's
_PRT is exposed to OSX, and OSX, seeing the PCI bus/device/func
addresses of the UHCI controllers, *and* seeing their respective PINs,
*and* seeing their respective LNKx links (from the DSDT), maps the
function to some interrupt that kills the device.

This is consistent with your results (if you change the PINs in the
source code, things work). It would be interesting to see what happens
if you shuffle the PCI addresses of the UHCI controllers.

... Hm. You did mention in the thread starter that chameleon runs on top
of SeaBIOS. SeaBIOS does have an ACPI linker/loader client, which would
explain why you see the same DSDT. The only thing that could differ
between the two cases is the LNK_IRQ() assignment then (ie. how OSX
chooses to map PCI interrupt links to IRQs), and I don't know why that
would be different. A /proc/interrupts table would be useful, again.

(Sorry about all the crazy errors I must have said above about PCI, ACPI
etc etc etc. Even if it turns out to be incorrect to some degree, if it
helps others help you, then it wasn't in vain.)

Laszlo

> I'm going
> to take some time to do a more thorough search of any and all logging
> I can find on OS X, and also try to find wherever in ovmf the guest
> device irq pin comes into play where uhci is concerned.
> 
> I am basically just poking at it with a stick right now, but maybe
> something will start making sense soon :)
> 
> Thanks again,
> --Gabriel
> 

Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse

[Gabriel L. Somlo]

On Mon, Sep 15, 2014 at 08:02:04PM +0200, Laszlo Ersek wrote:
> >> 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?
> > 
> > Actually, even more exciting:
> > 
> > diff --git a/hw/usb/hcd-uhci.c b/hw/usb/hcd-uhci.c
> > index 3b3ebcd..d61656e 100644
> > --- a/hw/usb/hcd-uhci.c
> > +++ b/hw/usb/hcd-uhci.c
> > @@ -1335,21 +1335,21 @@ static UHCIInfo uhci_info[] = {
> >          .vendor_id = PCI_VENDOR_ID_INTEL,
> >          .device_id = PCI_DEVICE_ID_INTEL_82801I_UHCI1,
> >          .revision  = 0x03,
> > -        .irq_pin   = 0,
> > +        .irq_pin   = 1,
> >          .unplug    = false,
> >      },{
> >          .name      = "ich9-usb-uhci2", /* 00:1d.1 */
> >          .vendor_id = PCI_VENDOR_ID_INTEL,
> >          .device_id = PCI_DEVICE_ID_INTEL_82801I_UHCI2,
> >          .revision  = 0x03,
> > -        .irq_pin   = 1,
> > +        .irq_pin   = 2,
> >          .unplug    = false,
> >      },{
> >          .name      = "ich9-usb-uhci3", /* 00:1d.2 */
> >          .vendor_id = PCI_VENDOR_ID_INTEL,
> >          .device_id = PCI_DEVICE_ID_INTEL_82801I_UHCI3,
> >          .revision  = 0x03,
> > -        .irq_pin   = 2,
> > +        .irq_pin   = 3,
> >          .unplug    = false,
> >      },{
> >          .name      = "ich9-usb-uhci4", /* 00:1a.0 */
> > 
> > Turns out, anything with an irq_pin <= 1 won't show up when osx is
> > booted on q35 with ovmf (but osx + q35 works if booted via Chameleon).

OK, so I forgot to articulate that with the above patch, I'm seeing
*both* uhci2 and uhci3, but not uhci1. Basically, if uhciX has an
irq_pin less than 2, it won't show up in OSX if booted with ovmf.
We're no longer looking at PIIX, this is q35 with ovmf or without.

> > 
> > DSDT looks identical across the ovmf vs. chameleon divide.
> 
> Now I'm curious. What's this chameleon thing? (Yes, I did find the
> homepage. Apparently the lead developer is a fellow Hungarian. A small
> world.) I'm surprised how you can get the same DSDT under both OVMF and
> chameleon. Assuming you run a recent OVMF on a recent QEMU, the DSDT
> exposed to the guest will originate from QEMU. This is confirmed by your
> q35.log that you sent me in private (due to its size) previously:
> 
...
> 
> I've got no clue how you can end up with the exact same DSDT under
> chameleon, unless it has a client for QEMU's fw_cfg ACPI linker/loader.

Chameleon is a multistage bootloader which can be started by a PC-BIOS
based machine, and which can then load OSX's /mach_kernel file from
the root directory of the main HFS+ partition (as opposed to loading
and running /System/Library/CoreServices/boot.efi, which is how an EFI
compatible BIOS would do it natively.

With qemu, I'm "side-loading" Chameleon's stage-2 loader. I.e., I
won't bother loading all the stages via the bios from the hard drive.
Instead, I add "-kernel chameleon_stage2_loader" to the qemu command
line, which bypasses all earlier stages.

While Chameleon *can* override the DSDT of its underlying machine
by accessing a .plist config file dropped into the root of the OS X
file system (i.e., that's how it's done on a hackintosh), in my case
I don't need to do that, as QEMU already provides a perfectly adequate
DSDT, so Chameleon just leaves it alone and proceeds to boot the mach
kernel.

I downloaded a DSDT ripper for the Mac (DSDTEditor_Mac.zip) I found via
from some forum or another (insanelymac.com or osx86project.org or
tonymacx86.com, don't remember precisely anymore) and dumped the DSDT
from inside OSX after having booted it with Chameleon-on-top-of-SeaBIOS on
one hand, or OVMF on the other. They look identical. It's just that
when using ovmf, the uhci irq_pin less-than-two invisibility thing kicks
in for some weird reason I'm still looking for :)

> In fact I think that should be *precisely* the difference here. The PCI
> interrupt routing table (_PRT) in the DSDT describes a two-level
> mapping. (I've probably forgotten most of the details, sorry.) First, it
> maps each PCI (bus, dev, pin) triplet to a PNP0C0F ("PCI interrupt
> link") device. We usually call these LNKA, LNKB, LNC, LNKD, LNKS on
> i440fx; there are more on q35. Then, each LNKx specifies a set of
> possible legacy interrupts that the link can be programmed for /
> assigned to. At runtime, the OS programs each of the interrupt links to
> one of its allowed legacy interrupts, and then all the pins (across
> buses and functions) that are connected to that interrupt link will
> trigger that interrupt. The OS usually tries to come up with a mapping
> (from LNKx to IRQ) so that interrupt sharing is minimized.
> 
> Here's an example from my i440fx Fedora 20 VM.
> 
> (1) The dmesg says first
> 
>   ACPI: PCI Interrupt Link [LNKA] (IRQs 5 10 *11)
>   ACPI: PCI Interrupt Link [LNKB] (IRQs 5 10 *11)
>   ACPI: PCI Interrupt Link [LNKC] (IRQs 5 *10 11)
>   ACPI: PCI Interrupt Link [LNKD] (IRQs 5 *10 11)
>   ACPI: PCI Interrupt Link [LNKS] (IRQs *9)
> 
> This displays what IRQs the _PRT in the DSDT allows for each of the LNKx
> links, and the asterisks show (IIRC) what elements of those sets are
> selected (programmed) when Linux inherits the hardware.
> 
> (2) Later it logs
> 
>   ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 10
>   ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11
>   ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
>   ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10
> 
> Let's call this mapping LNK_IRQ().
> 
> (3) Then look for the uchi controllers:
> 
>   uhci_hcd 0000:00:07.0: irq 10, io base 0x0000c0c0
>   uhci_hcd 0000:00:07.1: irq 11, io base 0x0000c0a0
>   uhci_hcd 0000:00:07.2: irq 11, io base 0x0000c080
> 
> And /proc/interrupts is consistent with that:
> 
>              CPU0       CPU1       
>    10:          6         25   IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb2
>    11:          0          0   IO-APIC-fasteoi   uhci_hcd:usb3, uhci_hcd:usb4, virtio2
> 
> These last two blocks are *results*.
> 
> Again, this is the result of composing two functions:
> 
>   device_interrupt = LNK_IRQ(PRT(bus, dev, pin))
> 
> PRT() comes from the DSDT, and maps (bus, dev, pin) to a link, while
> LNK_IRQ() comes from the OS (the actual link -> IRQ assignment), and is
> restricted to the possibilities offered in the DSDT.
> 
> The PRT that QEMU generates follows a rotating pattern (it is not
> restricted by physical circuits). As you go from one PCI device to the
> next, the same LNKA - LNKD links are distributed over the device's pins,
> but the sequence is shifted by one. The idea is that most PCI devices
> use only their first pin (INTA), and placing such devices "beside" each
> other should nicely iterate over all links, evenly.
> 
> Thus far I didn't speak about functions of the same PCI device. I didn't
> do that because I'm uneducated (even more than in the above :)). The
> basic idea is that different functions of the device will use different
> pins. Most devices are single-function, hence they usually stick with
> INTA. If you've got a multifunction device, then the functions will use
> separate pins.
> 
> For example, if I dump and decompile the DSDT in the guest, for bus 0
> device 7, I get, from the PRT:
> 
>   Package (0x04) { 0x0007FFFF,  Zero,  LNKC,  Zero },  <-- pin 0 / INTA
>   Package (0x04) { 0x0007FFFF,  One,  LNKD,  Zero },   <-- pin 1 / INTB
>   Package (0x04) { 0x0007FFFF,  0x02,  LNKA,  Zero },  <-- pin 2 / INTC
>   Package (0x04) { 0x0007FFFF,  0x03,  LNKB,  Zero },  <-- pin 3 / INTD
> 
> Let's put it all together, for a QEMU command line with
> 
>   -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x7
>   -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x7.0x1
>   -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x7.0x2
> 
> dev & func,  pin, set  interrupt link  IRQ programmed
> set on qemu  in qemu   for dev & pin,  by Linux for
> cmdline      source    set in DSDT     link
> -----------  --------  --------------  --------------
> 07.0                0            LNKC              10
> 07.1                1            LNKD              11
> 07.2                2            LNKA              11
> 
> The first two columns are input parameters (from the command line and
> from the source code). The third colum is the result of evaluating PRT()
> on the input params. The fourth column is the result of evaluating
> Linux's LNK_IRQ() function on the third column.
> 
> (Note that all of the above is for i440fx, not q35, but the method is
> similar.)

Thanks for this crash course, this is really useful stuff to know!

> Ultimately, I think that the difference between OVMF and chameleon is
> the following: when booting OSX with chameleon, QEMU's rotating _PRT is
> not exposed to OSX, because chameleon doesn't know how to download and
> interpret the necessary fw_cfg blobs. (What _PRT OSX decides to use
> then, I can't imagine.) But when you boot OSX with OVMF, then QEMU's
> _PRT is exposed to OSX, and OSX, seeing the PCI bus/device/func
> addresses of the UHCI controllers, *and* seeing their respective PINs,
> *and* seeing their respective LNKx links (from the DSDT), maps the
> function to some interrupt that kills the device.
> 
> This is consistent with your results (if you change the PINs in the
> source code, things work). It would be interesting to see what happens
> if you shuffle the PCI addresses of the UHCI controllers.
> 
> ... Hm. You did mention in the thread starter that chameleon runs on top
> of SeaBIOS. SeaBIOS does have an ACPI linker/loader client, which would
> explain why you see the same DSDT. The only thing that could differ
> between the two cases is the LNK_IRQ() assignment then (ie. how OSX
> chooses to map PCI interrupt links to IRQs), and I don't know why that
> would be different. A /proc/interrupts table would be useful, again.
> 
> (Sorry about all the crazy errors I must have said above about PCI, ACPI
> etc etc etc. Even if it turns out to be incorrect to some degree, if it
> helps others help you, then it wasn't in vain.)

Since the DSDT as seen by the guest is identical regardless of whether I
boot via ovmf or seabios+chameleon, I assume the results of all these
mappings should end up being the same. I'll look for as close an
equivalent of "cat /proc/interrupts" on os x as I can find, and try to
sanity-check this assumption.

Thanks,
--Gabriel

Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse

[BALATON Zoltan]

On Mon, 15 Sep 2014, Gabriel L. Somlo wrote:
> mappings should end up being the same. I'll look for as close an
> equivalent of "cat /proc/interrupts" on os x as I can find, and try to
> sanity-check this assumption.

I think you can find these in the ioreg output. Try ioreg -lfw0 and look 
for IOInterruptSpecifiers or you can try different IORegistryPlanes with 
the -p option (I don't have OS X at hand to test). Alternatively there's a 
GUI tool to get the same info called IORegistryExplorer that used to be 
part of older XCode versions, not sure where can you get it now.

Regards,
BALATON Zoltan

Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse

[Gerd Hoffmann]

  Hi,

> OK, so I forgot to articulate that with the above patch, I'm seeing
> *both* uhci2 and uhci3, but not uhci1. Basically, if uhciX has an
> irq_pin less than 2, it won't show up in OSX if booted with ovmf.
> We're no longer looking at PIIX, this is q35 with ovmf or without.

Can you test what happens with piix4 + usb2?  (I suspect you can't as
osx will simply not boot then due to the piix4 being much older than the
intel port of osx).

I think ovmf simply doesn't get the IRQ routing right (doesn't
initialize PCI_INTERRUPT_LINE register correctly).  It is *not* the same
on piix and q35.  See piix_pci_slot_get_irq vs. mch_pci_slot_get_irq in
seabios source code.

I think if you boot linux guests with "noacpi" it will have trouble with
usb interrupts too.

cheers,
  Gerd

Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse

[Gabriel L. Somlo]

On Tue, Sep 16, 2014 at 10:15:20AM +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> > OK, so I forgot to articulate that with the above patch, I'm seeing
> > *both* uhci2 and uhci3, but not uhci1. Basically, if uhciX has an
> > irq_pin less than 2, it won't show up in OSX if booted with ovmf.
> > We're no longer looking at PIIX, this is q35 with ovmf or without.
> 
> Can you test what happens with piix4 + usb2?  (I suspect you can't as
> osx will simply not boot then due to the piix4 being much older than the
> intel port of osx).

By default, when running OS X on PIIX, I get this in qtree:

      dev: piix3-usb-uhci, id ""
        masterbus = ""
        firstport = 0 (0x0)
        bandwidth = 1280 (0x500)
        maxframes = 128 (0x80)
        addr = 01.2
        romfile = ""
        rombar = 1 (0x1)
        multifunction = false
        command_serr_enable = true
        class USB controller, addr 00:01.2, pci id 8086:7020 (sub 1af4:1100)
        bar 4: i/o at 0xc060 [0xc07f]
        bus: usb-bus.0
          type usb-bus
          dev: usb-hub, id ""
            port = ""
            serial = ""
            full-path = true
            msos-desc = true
            addr 0.2, port 2, speed 12, name QEMU USB Hub, attached
          dev: usb-mouse, id ""
            usb_version = 2 (0x2)
            port = ""
            serial = ""
            full-path = true
            msos-desc = true
            addr 0.3, port 2.1, speed 12, name QEMU USB Mouse, attached
          dev: usb-kbd, id ""
            usb_version = 2 (0x2)
            display = ""
            port = ""
            serial = ""
            full-path = true
            msos-desc = true
            addr 0.1, port 1, speed 12, name QEMU USB Keyboard, attached

irq_pin for piix3-usb-uhci is set to 3 (in hcd-uhci.c); I tried setting
it to 2 (which changes device addresses on the usb bus to 0.3, 0.4, 0.2,
respectively) and to 1 (which restores device addresses to the same
values as irq_pin==3). Everything continues to work with both ovmf and
with seabios/chameleon.

However, using irq_pin = 0 for piix3-usb-uhci gets me the broken ovmf
behavior, while continuing to work fine with seabios/chameleon. Qtree
output is identical to when irq_pin was 2 (i.e. hub addr is 0.3, mouse
addr. is 0.4, and kbd addr. is 0.2, but otherwise identical to the above).

> I think ovmf simply doesn't get the IRQ routing right (doesn't
> initialize PCI_INTERRUPT_LINE register correctly).  It is *not* the same
> on piix and q35.  See piix_pci_slot_get_irq vs. mch_pci_slot_get_irq in
> seabios source code.

I'll go study that next... :)

> I think if you boot linux guests with "noacpi" it will have trouble with
> usb interrupts too.

Linux doesn't seem to care, and keyboard+mouse work fine when booted
with "noacpi" on the kernel command line. Actually, Linux seems to
recover as soon as grub loads and runs (or whatever component generates
the "start fedora live" vs. "test media and start fedora" vs.
"troubleshooting" menu).

Holding down a key (e.g. enter) while OVMF boots will cause "usb-kbd:
warning: key event queue full" warnings to qemu stdout, but they stop
as soon as either grub is launched (on either piix or q35), or the OSX
bootloader is fired up on piix. They don't stop on OS X + q35, which
means that whatever state OVMF left the q35 USB hardware in isn't making
OS X happy, but Grub (and Linux) can deal with it...


On Mon, Sep 15, 2014 at 09:56:29PM +0200, BALATON Zoltan wrote:
> I think you can find these in the ioreg output. Try ioreg -lfw0 and look for
> IOInterruptSpecifiers or you can try different IORegistryPlanes with the -p
> option (I don't have OS X at hand to test). Alternatively there's a GUI tool
> to get the same info called IORegistryExplorer that used to be part of older
> XCode versions, not sure where can you get it now.

It appears that ich9-usb-uhci[1,2] remain uninitialized. Below is a diff
I obtained after a bit of doctoring the ioreg output, which illustrates
the differences between booting with seabios/chameleon (working) vs. OVMF
(non-working).

Thanks,
--Gabriel

--- ioreg-uhci-chameleon.txt	2014-09-21 14:41:49.044185884 -0400
+++ ioreg-uhci-edk2_ovmf.txt	2014-09-16 15:25:25.723848777 -0400
@@ -1,277 +1,111 @@
- +-o SE8@1D  <class IOPCIDevice, id 0x10000014a, registered, matched, active, busy 0 (127 ms), retain 11>
+ +-o SE8@1D  <class IOPCIDevice, id 0x10000014e, registered, matched, active, busy 0 (16 ms), retain 9>
  |   {
  |     "acpi-path" = "IOACPIPlane:/_SB/PCI0@0/SE8@1d0000"
  |     "acpi-device" = "IOACPIPlatformDevice is not serializable"
  |     "built-in" = <00>
  |     "IOName" = "pci8086,2934"
  |     "name" = <"pci8086,2934">
  |     "compatible" = <"pci1af4,1100","pci8086,2934","pciclass,0c0300","SE8">
  |     "vendor-id" = <86800000>
  |     "subsystem-id" = <00110000>
  |     "subsystem-vendor-id" = <f41a0000>
  |     "revision-id" = <03000000>
  |     "pcidebug" = "0:29:0"
  |     "class-code" = <00030c00>
  |     "device-id" = <"4)">
  |     "assigned-addresses" = 
- |       00: phys.hi: 8100e820 phys.mid: 00000000 phys.lo: 0000c080
+ |       00: phys.hi: 8100e820 phys.mid: 00000000 phys.lo: 0000c0e0
  |           size.hi: 00000000 size.lo: 00000020
  |           bus: 0 dev: 29 func: 0 reg: 32
  |           type: I/O flags: abs
  |     "reg" = 
  |       00000000: 00 E8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20 E8 00 01 00 00 00 00 00 00 00 00 .................... ...........
  |       00000020: 00 00 00 00 20 00 00 00                                                                         .... ...
- |     "IOPowerManagement" = {"ChildrenPowerState"=2,"CurrentPowerState"=2,"ChildProxyPowerState"=2,"MaxPowerState"=3}
+ |     "IOPowerManagement" = {"MaxPowerState"=3,"ChildProxyPowerState"=2,"CurrentPowerState"=2}
  |     "IOPCIResourced" = Yes
  |     "IODeviceMemory" = ("IOSubMemoryDescriptor is not serializable")
- |     "IOInterruptControllers" = ("io-apic-0")
- |     "IOInterruptSpecifiers" = (<0a00000007000000>)
- |     "USBBusNumber" = 29
- |     "locationID" = 486539264
  |   }
  |   
- | | 
- | +-o AppleUSBUHCI  <class AppleUSBUHCI, id 0x10000016b, registered, matched, active, busy 0 (3 ms), retain 11>
- |   | {
- |   |   "IOClass" = "AppleUSBUHCI"
- |   |   "CFBundleIdentifier" = "com.apple.driver.AppleUSBUHCI"
- |   |   "IOProviderClass" = "IOPCIDevice"
- |   |   "Card Type" = "PCI"
- |   |   "IOPCIClassMatch" = "0x0C030000"
- |   |   "IOUserClientClass" = "IOUSBControllerUserClient"
- |   |   "IOPowerManagement" = {"ChildrenPowerState"=3,"DevicePowerState"=3,"CurrentPowerState"=3,"MaxPowerState"=4,"DriverPowerState"=3}
- |   |   "IOProbeScore" = 0
- |   |   "IOMatchCategory" = "IODefaultMatchCategory"
- |   |   "Errata" = 0
- |   |   "Companion" = "yes"
- |   |   "Need contiguous memory for isoch" = Yes
- |   | }
- |   | 
- |   +-o UHCI Root Hub Simulation@1D  <class IOUSBRootHubDevice, id 0x10000018e, registered, matched, active, busy 0 (3 ms), retain 9>
- |     | {
- |     |   "sessionID" = 607144662
- |     |   "Low Power Displayed" = No
- |     |   "iManufacturer" = 2
- |     |   "bNumConfigurations" = 1
- |     |   "idProduct" = 32773
- |     |   "bcdDevice" = 272
- |     |   "Bus Power Available" = 250
- |     |   "bMaxPacketSize0" = 8
- |     |   "USB Product Name" = "UHCI Root Hub Simulation"
- |     |   "iProduct" = 1
- |     |   "iSerialNumber" = 0
- |     |   "USB Address" = 1
- |     |   "bDeviceClass" = 9
- |     |   "locationID" = 486539264
- |     |   "bDeviceSubClass" = 0
- |     |   "IOUserClientClass" = "IOUSBDeviceUserClientV2"
- |     |   "Ports" = 2
- |     |   "IOCFPlugInTypes" = {"9dc7b780-9ec0-11d4-a54f-000a27052861"="IOUSBFamily.kext/Contents/PlugIns/IOUSBLib.bundle"}
- |     |   "bDeviceProtocol" = 0
- |     |   "USB Vendor Name" = "Apple Inc."
- |     |   "Device Speed" = 1
- |     |   "idVendor" = 1452
- |     |   "Requested Power" = 0
- |     |   "IOGeneralInterest" = "IOCommand is not serializable"
- |     |   "AAPL,current-extra-in-sleep" = 500
- |     |   "AAPL,max-port-current-in-sleep" = 1000
- |     |   "AAPL,standard-port-current-in-sleep" = 500
- |     | }
- |     | 
- |     +-o AppleUSBHub  <class AppleUSBHub, id 0x100000190, registered, matched, active, busy 0 (0 ms), retain 7>
- |     |   {
- |     |     "IOProbeScore" = 50000
- |     |     "CFBundleIdentifier" = "com.apple.driver.AppleUSBHub"
- |     |     "IOProviderClass" = "IOUSBDevice"
- |     |     "IOClass" = "AppleUSBHub"
- |     |     "bDeviceSubClass" = 0
- |     |     "IOMatchCategory" = "IODefaultMatchCategory"
- |     |     "Errata" = 0
- |     |     "Interrupt Pending" = No
- |     |     "IOPowerManagement" = {"DevicePowerState"=3,"CurrentPowerState"=3,"MaxPowerState"=4,"DriverPowerState"=3}
- |     |     "IOUserClientClass" = "AppleUSBHSHubUserClient"
- |     |     "bDeviceClass" = 9
- |     |   }
- |     |   
- |     +-o IOUSBInterface@0  <class IOUSBInterface, id 0x100000192, !registered, !matched, active, busy 0, retain 7>
- |         {
- |           "bcdDevice" = 272
- |           "idProduct" = 32773
- |           "bConfigurationValue" = 1
- |           "bInterfaceSubClass" = 0
- |           "locationID" = 486539264
- |           "idVendor" = 1452
- |           "iInterface" = 0
- |           "bAlternateSetting" = 0
- |           "bInterfaceProtocol" = 0
- |           "bInterfaceNumber" = 0
- |           "bInterfaceClass" = 9
- |           "bNumEndpoints" = 1
- |         }
- |         
- +-o pci8086,2935@1D,1  <class IOPCIDevice, id 0x100000154, registered, matched, active, busy 0 (124 ms), retain 10>
+ +-o pci8086,2935@1D,1  <class IOPCIDevice, id 0x100000159, registered, matched, active, busy 0 (15 ms), retain 8>
  |   {
  |     "IOName" = "pci8086,2935"
  |     "name" = <"pci8086,2935">
  |     "compatible" = <"pci1af4,1100","pci8086,2935","pciclass,0c0300">
  |     "vendor-id" = <86800000>
  |     "subsystem-id" = <00110000>
  |     "subsystem-vendor-id" = <f41a0000>
  |     "revision-id" = <03000000>
  |     "pcidebug" = "0:29:1"
  |     "class-code" = <00030c00>
  |     "device-id" = <"5)">
  |     "assigned-addresses" = 
- |       00: phys.hi: 8100e920 phys.mid: 00000000 phys.lo: 0000c0a0
+ |       00: phys.hi: 8100e920 phys.mid: 00000000 phys.lo: 0000c0c0
  |           size.hi: 00000000 size.lo: 00000020
  |           bus: 0 dev: 29 func: 1 reg: 32
  |           type: I/O flags: abs
  |     "reg" = 
  |       00000000: 00 E9 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20 E9 00 01 00 00 00 00 00 00 00 00 .................... ...........
  |       00000020: 00 00 00 00 20 00 00 00                                                                         .... ...
- |     "IOPowerManagement" = {"ChildrenPowerState"=2,"CurrentPowerState"=2,"ChildProxyPowerState"=2,"MaxPowerState"=3}
+ |     "IOPowerManagement" = {"MaxPowerState"=3,"ChildProxyPowerState"=2,"CurrentPowerState"=2}
  |     "IOPCIResourced" = Yes
  |     "IODeviceMemory" = ("IOSubMemoryDescriptor is not serializable")
- |     "IOInterruptControllers" = ("io-apic-0")
- |     "IOInterruptSpecifiers" = (<0a00000007000000>)
- |     "USBBusNumber" = 61
- |     "locationID" = 1023410176
  |   }
  |   
- | | 
- | +-o AppleUSBUHCI  <class AppleUSBUHCI, id 0x100000169, registered, matched, active, busy 0 (3 ms), retain 11>
- |   | {
- |   |   "IOClass" = "AppleUSBUHCI"
- |   |   "CFBundleIdentifier" = "com.apple.driver.AppleUSBUHCI"
- |   |   "IOProviderClass" = "IOPCIDevice"
- |   |   "Card Type" = "PCI"
- |   |   "IOPCIClassMatch" = "0x0C030000"
- |   |   "IOUserClientClass" = "IOUSBControllerUserClient"
- |   |   "IOPowerManagement" = {"ChildrenPowerState"=3,"DevicePowerState"=3,"CurrentPowerState"=3,"MaxPowerState"=4,"DriverPowerState"=3}
- |   |   "IOProbeScore" = 0
- |   |   "IOMatchCategory" = "IODefaultMatchCategory"
- |   |   "Errata" = 0
- |   |   "Companion" = "yes"
- |   |   "Need contiguous memory for isoch" = Yes
- |   | }
- |   | 
- |   +-o UHCI Root Hub Simulation@1D,1  <class IOUSBRootHubDevice, id 0x100000189, registered, matched, active, busy 0 (3 ms), retain 9>
- |     | {
- |     |   "sessionID" = 602137484
- |     |   "Low Power Displayed" = No
- |     |   "iManufacturer" = 2
- |     |   "bNumConfigurations" = 1
- |     |   "idProduct" = 32773
- |     |   "bcdDevice" = 272
- |     |   "Bus Power Available" = 250
- |     |   "bMaxPacketSize0" = 8
- |     |   "USB Product Name" = "UHCI Root Hub Simulation"
- |     |   "iProduct" = 1
- |     |   "iSerialNumber" = 0
- |     |   "USB Address" = 1
- |     |   "bDeviceClass" = 9
- |     |   "locationID" = 1023410176
- |     |   "bDeviceSubClass" = 0
- |     |   "IOUserClientClass" = "IOUSBDeviceUserClientV2"
- |     |   "Ports" = 2
- |     |   "IOCFPlugInTypes" = {"9dc7b780-9ec0-11d4-a54f-000a27052861"="IOUSBFamily.kext/Contents/PlugIns/IOUSBLib.bundle"}
- |     |   "bDeviceProtocol" = 0
- |     |   "USB Vendor Name" = "Apple Inc."
- |     |   "Device Speed" = 1
- |     |   "idVendor" = 1452
- |     |   "Requested Power" = 0
- |     |   "IOGeneralInterest" = "IOCommand is not serializable"
- |     |   "AAPL,current-extra-in-sleep" = 500
- |     |   "AAPL,max-port-current-in-sleep" = 1000
- |     |   "AAPL,standard-port-current-in-sleep" = 500
- |     | }
- |     | 
- |     +-o AppleUSBHub  <class AppleUSBHub, id 0x10000018b, registered, matched, active, busy 0 (0 ms), retain 7>
- |     |   {
- |     |     "IOProbeScore" = 50000
- |     |     "CFBundleIdentifier" = "com.apple.driver.AppleUSBHub"
- |     |     "IOProviderClass" = "IOUSBDevice"
- |     |     "IOClass" = "AppleUSBHub"
- |     |     "bDeviceSubClass" = 0
- |     |     "IOMatchCategory" = "IODefaultMatchCategory"
- |     |     "Errata" = 0
- |     |     "Interrupt Pending" = No
- |     |     "IOPowerManagement" = {"DevicePowerState"=3,"CurrentPowerState"=3,"MaxPowerState"=4,"DriverPowerState"=3}
- |     |     "IOUserClientClass" = "AppleUSBHSHubUserClient"
- |     |     "bDeviceClass" = 9
- |     |   }
- |     |   
- |     +-o IOUSBInterface@0  <class IOUSBInterface, id 0x10000018d, !registered, !matched, active, busy 0, retain 7>
- |         {
- |           "bcdDevice" = 272
- |           "idProduct" = 32773
- |           "bConfigurationValue" = 1
- |           "bInterfaceSubClass" = 0
- |           "locationID" = 1023410176
- |           "idVendor" = 1452
- |           "iInterface" = 0
- |           "bAlternateSetting" = 0
- |           "bInterfaceProtocol" = 0
- |           "bInterfaceNumber" = 0
- |           "bInterfaceClass" = 9
- |           "bNumEndpoints" = 1
- |         }
- |         
- +-o pci8086,2936@1D,2  <class IOPCIDevice, id 0x100000155, registered, matched, active, busy 0 (123 ms), retain 10>
+ +-o pci8086,2936@1D,2  <class IOPCIDevice, id 0x10000015a, registered, matched, active, busy 0 (121 ms), retain 10>
  | | {
  | |   "IOName" = "pci8086,2936"
  | |   "name" = <"pci8086,2936">
  | |   "compatible" = <"pci1af4,1100","pci8086,2936","pciclass,0c0300">
  | |   "vendor-id" = <86800000>
  | |   "subsystem-id" = <00110000>
  | |   "subsystem-vendor-id" = <f41a0000>
  | |   "revision-id" = <03000000>
  | |   "pcidebug" = "0:29:2"
  | |   "class-code" = <00030c00>
  | |   "device-id" = <"6)">
  | |   "assigned-addresses" = 
- | |     00: phys.hi: 8100ea20 phys.mid: 00000000 phys.lo: 0000c0c0
+ | |     00: phys.hi: 8100ea20 phys.mid: 00000000 phys.lo: 0000c0a0
  | |         size.hi: 00000000 size.lo: 00000020
  | |         bus: 0 dev: 29 func: 2 reg: 32
  | |         type: I/O flags: abs
  | |   "reg" = 
  | |     00000000: 00 EA 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20 EA 00 01 00 00 00 00 00 00 00 00 .................... ...........
  | |     00000020: 00 00 00 00 20 00 00 00                                                                         .... ...
  | |   "IOPowerManagement" = {"ChildrenPowerState"=2,"CurrentPowerState"=2,"ChildProxyPowerState"=2,"MaxPowerState"=3}
  | |   "IOPCIResourced" = Yes
  | |   "IODeviceMemory" = ("IOSubMemoryDescriptor is not serializable")
  | |   "IOInterruptControllers" = ("io-apic-0")
  | |   "IOInterruptSpecifiers" = (<1200000007000000>)
  | |   "USBBusNumber" = 93
  | |   "locationID" = 1560281088
  | | }
  | | 
- | +-o AppleUSBUHCI  <class AppleUSBUHCI, id 0x10000016c, registered, matched, active, busy 0 (3 ms), retain 11>
+ | +-o AppleUSBUHCI  <class AppleUSBUHCI, id 0x100000178, registered, matched, active, busy 0 (3 ms), retain 11>
  |   | {
  |   |   "IOClass" = "AppleUSBUHCI"
  |   |   "CFBundleIdentifier" = "com.apple.driver.AppleUSBUHCI"
  |   |   "IOProviderClass" = "IOPCIDevice"
  |   |   "Card Type" = "PCI"
  |   |   "IOPCIClassMatch" = "0x0C030000"
  |   |   "IOUserClientClass" = "IOUSBControllerUserClient"
  |   |   "IOPowerManagement" = {"ChildrenPowerState"=3,"DevicePowerState"=3,"CurrentPowerState"=3,"MaxPowerState"=4,"DriverPowerState"=3}
  |   |   "IOProbeScore" = 0
  |   |   "IOMatchCategory" = "IODefaultMatchCategory"
  |   |   "Errata" = 0
  |   |   "Companion" = "yes"
  |   |   "Need contiguous memory for isoch" = Yes
  |   | }
  |   | 
- |   +-o UHCI Root Hub Simulation@1D,2  <class IOUSBRootHubDevice, id 0x100000184, registered, matched, active, busy 0 (3 ms), retain 9>
+ |   +-o UHCI Root Hub Simulation@1D,2  <class IOUSBRootHubDevice, id 0x100000188, registered, matched, active, busy 0 (3 ms), retain 9>
  |     | {
- |     |   "sessionID" = 597168905
+ |     |   "sessionID" = 634036749
  |     |   "Low Power Displayed" = No
  |     |   "iManufacturer" = 2
  |     |   "bNumConfigurations" = 1
  |     |   "idProduct" = 32773
  |     |   "bcdDevice" = 272
  |     |   "Bus Power Available" = 250
  |     |   "bMaxPacketSize0" = 8
  |     |   "USB Product Name" = "UHCI Root Hub Simulation"
  |     |   "iProduct" = 1
  |     |   "iSerialNumber" = 0
@@ -281,41 +115,38 @@
  |     |   "bDeviceSubClass" = 0
  |     |   "IOUserClientClass" = "IOUSBDeviceUserClientV2"
  |     |   "Ports" = 2
  |     |   "IOCFPlugInTypes" = {"9dc7b780-9ec0-11d4-a54f-000a27052861"="IOUSBFamily.kext/Contents/PlugIns/IOUSBLib.bundle"}
  |     |   "bDeviceProtocol" = 0
  |     |   "USB Vendor Name" = "Apple Inc."
  |     |   "Device Speed" = 1
  |     |   "idVendor" = 1452
  |     |   "Requested Power" = 0
  |     |   "IOGeneralInterest" = "IOCommand is not serializable"
- |     |   "AAPL,current-extra-in-sleep" = 500
- |     |   "AAPL,max-port-current-in-sleep" = 1000
- |     |   "AAPL,standard-port-current-in-sleep" = 500
  |     | }
  |     | 
- |     +-o AppleUSBHub  <class AppleUSBHub, id 0x100000186, registered, matched, active, busy 0 (0 ms), retain 7>
+ |     +-o AppleUSBHub  <class AppleUSBHub, id 0x10000018a, registered, matched, active, busy 0 (0 ms), retain 7>
  |     |   {
  |     |     "IOProbeScore" = 50000
  |     |     "CFBundleIdentifier" = "com.apple.driver.AppleUSBHub"
  |     |     "IOProviderClass" = "IOUSBDevice"
  |     |     "IOClass" = "AppleUSBHub"
  |     |     "bDeviceSubClass" = 0
  |     |     "IOMatchCategory" = "IODefaultMatchCategory"
  |     |     "Errata" = 0
  |     |     "Interrupt Pending" = No
  |     |     "IOPowerManagement" = {"DevicePowerState"=3,"CurrentPowerState"=3,"MaxPowerState"=4,"DriverPowerState"=3}
  |     |     "IOUserClientClass" = "AppleUSBHSHubUserClient"
  |     |     "bDeviceClass" = 9
  |     |   }
  |     |   
- |     +-o IOUSBInterface@0  <class IOUSBInterface, id 0x100000188, !registered, !matched, active, busy 0, retain 7>
+ |     +-o IOUSBInterface@0  <class IOUSBInterface, id 0x10000018c, !registered, !matched, active, busy 0, retain 7>
  |         {
  |           "bcdDevice" = 272
  |           "idProduct" = 32773
  |           "bConfigurationValue" = 1
  |           "bInterfaceSubClass" = 0
  |           "locationID" = 1560281088
  |           "idVendor" = 1452
  |           "iInterface" = 0
  |           "bAlternateSetting" = 0
  |           "bInterfaceProtocol" = 0

Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse

[Gabriel L. Somlo]

On Mon, Sep 15, 2014 at 08:02:04PM +0200, Laszlo Ersek wrote:
> Here's an example from my i440fx Fedora 20 VM.
> 
> (1) The dmesg says first
> 
>   ACPI: PCI Interrupt Link [LNKA] (IRQs 5 10 *11)
>   ACPI: PCI Interrupt Link [LNKB] (IRQs 5 10 *11)
>   ACPI: PCI Interrupt Link [LNKC] (IRQs 5 *10 11)
>   ACPI: PCI Interrupt Link [LNKD] (IRQs 5 *10 11)
>   ACPI: PCI Interrupt Link [LNKS] (IRQs *9)
> 
> This displays what IRQs the _PRT in the DSDT allows for each of the LNKx
> links, and the asterisks show (IIRC) what elements of those sets are
> selected (programmed) when Linux inherits the hardware.
> 
> (2) Later it logs
> 
>   ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 10
>   ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11
>   ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
>   ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10
> 
> Let's call this mapping LNK_IRQ().
> 
> (3) Then look for the uchi controllers:
> 
>   uhci_hcd 0000:00:07.0: irq 10, io base 0x0000c0c0
>   uhci_hcd 0000:00:07.1: irq 11, io base 0x0000c0a0
>   uhci_hcd 0000:00:07.2: irq 11, io base 0x0000c080
> 
> And /proc/interrupts is consistent with that:
> 
>              CPU0       CPU1       
>    10:          6         25   IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb2
>    11:          0          0   IO-APIC-fasteoi   uhci_hcd:usb3, uhci_hcd:usb4, virtio2
> 
> These last two blocks are *results*.

Using F20-live on Q35 with SeaBIOS vs. OVMF, I get:

$> grep LNK dmsg*.log

dmsg_bios.log: ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11)
dmsg_bios.log: ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11)
dmsg_bios.log: ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11)
dmsg_bios.log: ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 *11)
dmsg_bios.log: ACPI: PCI Interrupt Link [LNKE] (IRQs 5 *10 11)
dmsg_bios.log: ACPI: PCI Interrupt Link [LNKF] (IRQs 5 *10 11)
dmsg_bios.log: ACPI: PCI Interrupt Link [LNKG] (IRQs 5 10 *11)
dmsg_bios.log: ACPI: PCI Interrupt Link [LNKH] (IRQs 5 10 *11)

dmsg_ovmf.log: ACPI: PCI Interrupt Link [LNKA] (IRQs 5 10 11) *0, disabled.
dmsg_ovmf.log: ACPI: PCI Interrupt Link [LNKB] (IRQs 5 10 11) *0, disabled.
dmsg_ovmf.log: ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 11) *0, disabled.
dmsg_ovmf.log: ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 11) *0, disabled.
dmsg_ovmf.log: ACPI: PCI Interrupt Link [LNKE] (IRQs 5 10 11) *0, disabled.
dmsg_ovmf.log: ACPI: PCI Interrupt Link [LNKF] (IRQs 5 10 11) *0, disabled.
dmsg_ovmf.log: ACPI: PCI Interrupt Link [LNKG] (IRQs 5 10 11) *0, disabled.
dmsg_ovmf.log: ACPI: PCI Interrupt Link [LNKH] (IRQs 5 10 11) *0, disabled.

Neither logs any "Link enabled at IRQ X" messages (at least not for
LNKX; they both do for GSIX, though). Wonder why it says "disabled"
on OVMF... This is the only suspicious (to me) difference between
SeaBIOS and OVMF with q35 and fedora.

$> grep uhci_hcd dmsg*.log

dmsg_bios.log: uhci_hcd: USB Universal Host Controller Interface driver
dmsg_bios.log: uhci_hcd 0000:00:1d.0: setting latency timer to 64
dmsg_bios.log: uhci_hcd 0000:00:1d.0: UHCI Host Controller
dmsg_bios.log: uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus # 2
dmsg_bios.log: uhci_hcd 0000:00:1d.0: irq 16, io base 0x0000c080
dmsg_bios.log: usb usb2: Manufacturer: Linux 3.11.10-301.fc20.x86_64 uhci_hcd
dmsg_bios.log: uhci_hcd 0000:00:1d.1: setting latency timer to 64
dmsg_bios.log: uhci_hcd 0000:00:1d.1: UHCI Host Controller
dmsg_bios.log: uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus # 3
dmsg_bios.log: uhci_hcd 0000:00:1d.1: irq 17, io base 0x0000c0a0
dmsg_bios.log: usb usb3: Manufacturer: Linux 3.11.10-301.fc20.x86_64 uhci_hcd
dmsg_bios.log: uhci_hcd 0000:00:1d.2: setting latency timer to 64
dmsg_bios.log: uhci_hcd 0000:00:1d.2: UHCI Host Controller
dmsg_bios.log: uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus # 4
dmsg_bios.log: uhci_hcd 0000:00:1d.2: irq 18, io base 0x0000c0c0
dmsg_bios.log: usb usb4: Manufacturer: Linux 3.11.10-301.fc20.x86_64 uhci_hcd

dmsg_ovmf.log: uhci_hcd: USB Universal Host Controller Interface driver
dmsg_ovmf.log: uhci_hcd 0000:00:1d.0: setting latency timer to 64
dmsg_ovmf.log: uhci_hcd 0000:00:1d.0: UHCI Host Controller
dmsg_ovmf.log: uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus # 2
dmsg_ovmf.log: uhci_hcd 0000:00:1d.0: irq 16, io base 0x0000c0e0
dmsg_ovmf.log: usb usb2: Manufacturer: Linux 3.11.10-301.fc20.x86_64 uhci_hcd
dmsg_ovmf.log: uhci_hcd 0000:00:1d.1: setting latency timer to 64
dmsg_ovmf.log: uhci_hcd 0000:00:1d.1: UHCI Host Controller
dmsg_ovmf.log: uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus # 3
dmsg_ovmf.log: uhci_hcd 0000:00:1d.1: irq 17, io base 0x0000c0c0
dmsg_ovmf.log: usb usb3: Manufacturer: Linux 3.11.10-301.fc20.x86_64 uhci_hcd
dmsg_ovmf.log: uhci_hcd 0000:00:1d.2: setting latency timer to 64
dmsg_ovmf.log: uhci_hcd 0000:00:1d.2: UHCI Host Controller
dmsg_ovmf.log: uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus # 4
dmsg_ovmf.log: uhci_hcd 0000:00:1d.2: irq 18, io base 0x0000c0a0
dmsg_ovmf.log: usb usb4: Manufacturer: Linux 3.11.10-301.fc20.x86_64 uhci_hcd

The IO base addresses are the only difference, not sure if this matters:

 pci    io_base_addr
device   bios  ovmf
---------------------
 1d.0    c080  c0e0
 1d.1    c0a0  c0c0
 1d.2    c0c0  c0a0

Finally, the relevant bits from /proc/interrupts:

with SeaBIOS:

 16:   0    0    0    0   IO-APIC-fasteoi   uhci_hcd:usb2, i801_smbus
 17:   0    0    0    0   IO-APIC-fasteoi   uhci_hcd:usb3
 18:   0    0    0    0   IO-APIC-fasteoi   uhci_hcd:usb4
 19:  55    0  341    0   IO-APIC-fasteoi   ehci_hcd:usb1

and with OVMF:

 16:   0    0    0    0   IO-APIC-fasteoi   uhci_hcd:usb2, i801_smbus
 17:   0    0    0    0   IO-APIC-fasteoi   uhci_hcd:usb3
 18:   0    0    0    0   IO-APIC-fasteoi   uhci_hcd:usb4
 19:  55    0  131    0   IO-APIC-fasteoi   ehci_hcd:usb1

So, basically, no difference. 

I'm off studying "pci_slot_get_irq" functions in SeaBIOS per Gerd's
suggestion, hopefully I can locate the equivalent functionality in
OVMF and spot some problem with it I can fix.

That might take me a while... :)

Thanks,
--Gabriel

Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse

[Laszlo Ersek]

On 09/22/14 00:10, Gabriel L. Somlo wrote:

> dmsg_bios.log: ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11)
> dmsg_bios.log: ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11)
> dmsg_bios.log: ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11)
> dmsg_bios.log: ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 *11)
> dmsg_bios.log: ACPI: PCI Interrupt Link [LNKE] (IRQs 5 *10 11)
> dmsg_bios.log: ACPI: PCI Interrupt Link [LNKF] (IRQs 5 *10 11)
> dmsg_bios.log: ACPI: PCI Interrupt Link [LNKG] (IRQs 5 10 *11)
> dmsg_bios.log: ACPI: PCI Interrupt Link [LNKH] (IRQs 5 10 *11)
> 
> dmsg_ovmf.log: ACPI: PCI Interrupt Link [LNKA] (IRQs 5 10 11) *0, disabled.
> dmsg_ovmf.log: ACPI: PCI Interrupt Link [LNKB] (IRQs 5 10 11) *0, disabled.
> dmsg_ovmf.log: ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 11) *0, disabled.
> dmsg_ovmf.log: ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 11) *0, disabled.
> dmsg_ovmf.log: ACPI: PCI Interrupt Link [LNKE] (IRQs 5 10 11) *0, disabled.
> dmsg_ovmf.log: ACPI: PCI Interrupt Link [LNKF] (IRQs 5 10 11) *0, disabled.
> dmsg_ovmf.log: ACPI: PCI Interrupt Link [LNKG] (IRQs 5 10 11) *0, disabled.
> dmsg_ovmf.log: ACPI: PCI Interrupt Link [LNKH] (IRQs 5 10 11) *0, disabled.

I mentioned earlier that grepping OvmfPkg for PCI_LIB_ADDRESS would be
necessary. See PciInitialization() in
"OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c".

  //
  // Bus 0, Device 1, Function 0 - PCI to ISA Bridge
  //
  PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x3c), 0x00);
  PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x60), 0x0b); // LNKA routing target
  PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x61), 0x0b); // LNKB routing target
  PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x62), 0x0a); // LNKC routing target
  PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x63), 0x0a); // LNKD routing target

This is not appropriate for q35. See "ICH9 PCI to ISA irq remapping" in
qemu's "q35-acpi-dsdt.dsl" file, vs. "PIIX PCI to ISA irq remapping" in
"acpi-dsdt.dsl".

The above was added in 05c89c7f.

Thanks
Laszlo

Re: [Qemu-devel] [edk2] OVMF, Q35 and USB keyboard/mouse

[Paolo Bonzini]

Il 22/09/2014 00:43, Laszlo Ersek ha scritto:
>   // Bus 0, Device 1, Function 0 - PCI to ISA Bridge
>   //
>   PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x3c), 0x00);
>   PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x60), 0x0b); // LNKA routing target
>   PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x61), 0x0b); // LNKB routing target
>   PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x62), 0x0a); // LNKC routing target
>   PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x63), 0x0a); // LNKD routing target
> 
> This is not appropriate for q35. See "ICH9 PCI to ISA irq remapping" in
> qemu's "q35-acpi-dsdt.dsl" file, vs. "PIIX PCI to ISA irq remapping" in
> "acpi-dsdt.dsl".

If I understand the DSDT right, the field is still at 0x60, but the
bridge is now at 1f.0.  Right?  Also, LNKE-LNKH must be set at 0x68.

However, these are only used if OS X runs in PIC mode rather than APIC
mode (see \_PIC).  Why should OS X be running in PIC mode?  So fixing
the above is right to do, but may not be enough.

Paolo

Re: [Qemu-devel] [edk2] OVMF, Q35 and USB keyboard/mouse

[Gabriel L. Somlo]

On Mon, Sep 22, 2014 at 06:44:26PM +0200, Paolo Bonzini wrote:
> Il 22/09/2014 00:43, Laszlo Ersek ha scritto:
> > I mentioned earlier that grepping OvmfPkg for PCI_LIB_ADDRESS would be
> > necessary. See PciInitialization() in
> > "OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c".

I remember that, but back then I hadn't RTFMed enough for it
to mean something useful to me. I get it now though, so thanks
for the repetition :)

> >   //
> >   // Bus 0, Device 1, Function 0 - PCI to ISA Bridge
> >   //
> >   PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x3c), 0x00);
> >   PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x60), 0x0b); // LNKA routing target
> >   PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x61), 0x0b); // LNKB routing target
> >   PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x62), 0x0a); // LNKC routing target
> >   PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x63), 0x0a); // LNKD routing target
> > 
> > This is not appropriate for q35. See "ICH9 PCI to ISA irq remapping" in
> > qemu's "q35-acpi-dsdt.dsl" file, vs. "PIIX PCI to ISA irq remapping" in
> > "acpi-dsdt.dsl".
> 
> If I understand the DSDT right, the field is still at 0x60, but the
> bridge is now at 1f.0.  Right?  Also, LNKE-LNKH must be set at 0x68.
> 
> However, these are only used if OS X runs in PIC mode rather than APIC
> mode (see \_PIC).  Why should OS X be running in PIC mode?  So fixing
> the above is right to do, but may not be enough.

I'll take a pass at making these dependent on the host bridge DID (same
as with the pmbase/pmtimer) instead of hard coded, then we'll see what
else breaks :)

Thanks again for 

Re: [Qemu-devel] [edk2] OVMF, Q35 and USB keyboard/mouse

[Laszlo Ersek]

On 09/22/14 18:44, Paolo Bonzini wrote:
> Il 22/09/2014 00:43, Laszlo Ersek ha scritto:
>>   // Bus 0, Device 1, Function 0 - PCI to ISA Bridge
>>   //
>>   PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x3c), 0x00);
>>   PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x60), 0x0b); // LNKA routing target
>>   PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x61), 0x0b); // LNKB routing target
>>   PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x62), 0x0a); // LNKC routing target
>>   PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x63), 0x0a); // LNKD routing target
>>
>> This is not appropriate for q35. See "ICH9 PCI to ISA irq remapping" in
>> qemu's "q35-acpi-dsdt.dsl" file, vs. "PIIX PCI to ISA irq remapping" in
>> "acpi-dsdt.dsl".
> 
> If I understand the DSDT right, the field is still at 0x60, but the
> bridge is now at 1f.0.  Right?  Also, LNKE-LNKH must be set at 0x68.
> 
> However, these are only used if OS X runs in PIC mode rather than APIC
> mode (see \_PIC).  Why should OS X be running in PIC mode?  So fixing
> the above is right to do, but may not be enough.

I agree completely. I mentioned this because of

dmsg_ovmf.log: ACPI: PCI Interrupt Link [LNKA] (IRQs 5 10 11) *0, disabled.
dmsg_ovmf.log: ACPI: PCI Interrupt Link [LNKB] (IRQs 5 10 11) *0, disabled.
dmsg_ovmf.log: ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 11) *0, disabled.
dmsg_ovmf.log: ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 11) *0, disabled.
dmsg_ovmf.log: ACPI: PCI Interrupt Link [LNKE] (IRQs 5 10 11) *0, disabled.
dmsg_ovmf.log: ACPI: PCI Interrupt Link [LNKF] (IRQs 5 10 11) *0, disabled.
dmsg_ovmf.log: ACPI: PCI Interrupt Link [LNKG] (IRQs 5 10 11) *0, disabled.
dmsg_ovmf.log: ACPI: PCI Interrupt Link [LNKH] (IRQs 5 10 11) *0, disabled.

Thanks,
Laszlo

Re: [Qemu-devel] [edk2] OVMF, Q35 and USB keyboard/mouse

[Gabriel L. Somlo]

On Mon, Sep 22, 2014 at 10:40:04PM +0200, Laszlo Ersek wrote:
> On 09/22/14 18:44, Paolo Bonzini wrote:
> > Il 22/09/2014 00:43, Laszlo Ersek ha scritto:
> >>   // Bus 0, Device 1, Function 0 - PCI to ISA Bridge
> >>   //
> >>   PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x3c), 0x00);
> >>   PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x60), 0x0b); // LNKA routing target
> >>   PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x61), 0x0b); // LNKB routing target
> >>   PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x62), 0x0a); // LNKC routing target
> >>   PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x63), 0x0a); // LNKD routing target
> >>
> >> This is not appropriate for q35. See "ICH9 PCI to ISA irq remapping" in
> >> qemu's "q35-acpi-dsdt.dsl" file, vs. "PIIX PCI to ISA irq remapping" in
> >> "acpi-dsdt.dsl".
> > 
> > If I understand the DSDT right, the field is still at 0x60, but the
> > bridge is now at 1f.0.  Right?  Also, LNKE-LNKH must be set at 0x68.

With the patch included below, I now get identical behavior in terms
of q35 LNK[A-H] between SeaBIOS and OVMF.

> > However, these are only used if OS X runs in PIC mode rather than APIC
> > mode (see \_PIC).  Why should OS X be running in PIC mode?  So fixing
> > the above is right to do, but may not be enough.

Grepping for GSIA on either SeaBIOS or OVMF looks the same:

[    0.000000] ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 0, version 17, address 0xfec00000, GSI 0-23
[    0.000000] nr_irqs_gsi: 40
[    0.195980] ACPI: PCI Interrupt Link [GSIA] (IRQs *16)
[    0.196012] ACPI: PCI Interrupt Link [GSIB] (IRQs *17)
[    0.196022] ACPI: PCI Interrupt Link [GSIC] (IRQs *18)
[    0.196031] ACPI: PCI Interrupt Link [GSID] (IRQs *19)
[    0.196041] ACPI: PCI Interrupt Link [GSIE] (IRQs *20)
[    0.196050] ACPI: PCI Interrupt Link [GSIF] (IRQs *21)
[    0.196059] ACPI: PCI Interrupt Link [GSIG] (IRQs *22)
[    0.196068] ACPI: PCI Interrupt Link [GSIH] (IRQs *23)
[    0.325959] ACPI: PCI Interrupt Link [GSIA] enabled at IRQ 16
[    0.327518] ACPI: PCI Interrupt Link [GSIB] enabled at IRQ 17
[    0.328839] ACPI: PCI Interrupt Link [GSIC] enabled at IRQ 18
[    0.330071] ACPI: PCI Interrupt Link [GSID] enabled at IRQ 19
[    2.432386] ACPI: PCI Interrupt Link [GSIG] enabled at IRQ 22

(and did so even before I fixed LNK*), but I still don't get UHCI1
and UHCI2 detected under OS X :(

Speaking of the patch: the original (piix) PciInitialization()
function touches a bunch of devices' interrupt line (0x3c) and
interrupt pin (0x3d) registers, but on q35/ich those are mostly
supposed to be unused or read-only, so I only did LNK routing
setup for the q35 version. Not enough clue yet to know if I'm
missing anything important.

Also, during PciInitializationQ35() I read and dumped the line and
pin register values for 00:1d.0-2, and got 0xff for line and 1,2,3
respectively for pin (as opposed to 0,1,2 as set up in qemu). Not
sure if that's important or not :)

Thanks,
--Gabriel


diff --git a/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c b/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c
index 9cc6068..380f07f 100644
--- a/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c
+++ b/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c
@@ -716,8 +716,9 @@ Returns:
 }
 
 
+STATIC
 VOID
-PciInitialization (
+PciInitializationPIIX (
   )
 {
   //
@@ -765,6 +766,55 @@ PciInitialization (
 }
 
 
+STATIC
+VOID
+PciInitializationQ35 (
+  )
+{
+  //
+  // Bus 0, Device 0x1f, Function 0 - LPC Bridge: Initialize PIC IRQ routing
+  //
+  PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x60), 0x0a); // LNKA routing target
+  PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x61), 0x0a); // LNKB routing target
+  PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x62), 0x0b); // LNKC routing target
+  PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x63), 0x0b); // LNKD routing target
+  PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x68), 0x0a); // LNKE routing target
+  PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x69), 0x0a); // LNKF routing target
+  PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x6a), 0x0b); // LNKG routing target
+  PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x6b), 0x0b); // LNKH routing target
+}
+
+
+//
+// Distinguish between Q35 and PIIX host bridges
+//
+#define PCI_DEVICE_ID_INTEL_82441    0x1237  // DID value for PIIX4
+#define PCI_DEVICE_ID_INTEL_Q35_MCH  0x29C0  // DID value for Q35
+
+#define HOSTBRIDGE_DID      PCI_LIB_ADDRESS (0, 0, 0, 0x02)
+#define IS_Q35_HOSTBRIDGE   (PciRead16 (HOSTBRIDGE_DID) == PCI_DEVICE_ID_INTEL_Q35_MCH)
+
+
+VOID
+PciInitialization (
+  )
+{
+  if (IS_Q35_HOSTBRIDGE) {
+    PciInitializationQ35 ();
+  } else {
+    PciInitializationPIIX ();
+  }
+}
+
+
+//
+// Locate PMCNTRL register (0x40) on the appropriate (Q35 vs. PIIX) host bridge
+//
+#define PMCNTRL_PIIX  PCI_LIB_ADDRESS (0,    1, 3, 0x40)
+#define PMCNTRL_Q35   PCI_LIB_ADDRESS (0, 0x1f, 0, 0x40)
+#define PMCNTRL       (IS_Q35_HOSTBRIDGE ? PMCNTRL_Q35 : PMCNTRL_PIIX)
+
+
 VOID
 AcpiInitialization (
   VOID
@@ -773,7 +823,7 @@ AcpiInitialization (
   //
   // Set ACPI SCI_EN bit in PMCNTRL
   //
-  IoOr16 ((PciRead32 (PCI_LIB_ADDRESS (0, 1, 3, 0x40)) & ~BIT0) + 4, BIT0);
+  IoOr16 ((PciRead32 (PMCNTRL) & ~BIT0) + 4, BIT0);
 }