* [Qemu-devel] OVMF, Q35 and USB keyboard/mouse @ 2014-09-09 22:00 Gabriel L. Somlo 2014-09-10 0:40 ` Laszlo Ersek 2014-09-10 6:31 ` Gerd Hoffmann 0 siblings, 2 replies; 37+ messages in thread From: Gabriel L. Somlo @ 2014-09-09 22:00 UTC (permalink / raw) To: qemu-devel; +Cc: agraf, edk2-devel, lersek, kraxel, reza.jelveh 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse 2014-09-09 22:00 [Qemu-devel] OVMF, Q35 and USB keyboard/mouse Gabriel L. Somlo @ 2014-09-10 0:40 ` Laszlo Ersek 2014-09-10 6:31 ` Gerd Hoffmann 1 sibling, 0 replies; 37+ messages in thread From: Laszlo Ersek @ 2014-09-10 0:40 UTC (permalink / raw) To: Gabriel L. Somlo, qemu-devel; +Cc: agraf, edk2-devel, kraxel, reza.jelveh 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse 2014-09-09 22:00 [Qemu-devel] OVMF, Q35 and USB keyboard/mouse Gabriel L. Somlo 2014-09-10 0:40 ` Laszlo Ersek @ 2014-09-10 6:31 ` Gerd Hoffmann 2014-09-10 7:59 ` Laszlo Ersek 1 sibling, 1 reply; 37+ messages in thread From: Gerd Hoffmann @ 2014-09-10 6:31 UTC (permalink / raw) To: Gabriel L. Somlo; +Cc: agraf, edk2-devel, lersek, qemu-devel, reza.jelveh 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse 2014-09-10 6:31 ` Gerd Hoffmann @ 2014-09-10 7:59 ` Laszlo Ersek 2014-09-10 14:06 ` Gabriel L. Somlo 0 siblings, 1 reply; 37+ messages in thread From: Laszlo Ersek @ 2014-09-10 7:59 UTC (permalink / raw) To: Gerd Hoffmann, Gabriel L. Somlo Cc: agraf, edk2-devel, qemu-devel, reza.jelveh 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse 2014-09-10 7:59 ` Laszlo Ersek @ 2014-09-10 14:06 ` Gabriel L. Somlo 2014-09-10 23:08 ` [Qemu-devel] [edk2] " Paolo Bonzini 0 siblings, 1 reply; 37+ messages in thread From: Gabriel L. Somlo @ 2014-09-10 14:06 UTC (permalink / raw) To: Laszlo Ersek; +Cc: edk2-devel, agraf, reza.jelveh, Gerd Hoffmann, qemu-devel 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Qemu-devel] [edk2] OVMF, Q35 and USB keyboard/mouse 2014-09-10 14:06 ` Gabriel L. Somlo @ 2014-09-10 23:08 ` Paolo Bonzini 2014-09-11 15:42 ` [Qemu-devel] " Gabriel L. Somlo 0 siblings, 1 reply; 37+ messages in thread From: Paolo Bonzini @ 2014-09-10 23:08 UTC (permalink / raw) To: edk2-devel, Laszlo Ersek; +Cc: qemu-devel 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse 2014-09-10 23:08 ` [Qemu-devel] [edk2] " Paolo Bonzini @ 2014-09-11 15:42 ` Gabriel L. Somlo 2014-09-11 15:49 ` Paolo Bonzini 0 siblings, 1 reply; 37+ messages in thread From: Gabriel L. Somlo @ 2014-09-11 15:42 UTC (permalink / raw) To: edk2-devel; +Cc: agraf, qemu-devel, kraxel, reza.jelveh, pbonzini, lersek 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse 2014-09-11 15:42 ` [Qemu-devel] " Gabriel L. Somlo @ 2014-09-11 15:49 ` Paolo Bonzini 2014-09-11 16:35 ` Gabriel L. Somlo 0 siblings, 1 reply; 37+ messages in thread From: Paolo Bonzini @ 2014-09-11 15:49 UTC (permalink / raw) To: Gabriel L. Somlo, edk2-devel Cc: agraf, reza.jelveh, lersek, qemu-devel, kraxel 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... :) ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse 2014-09-11 15:49 ` Paolo Bonzini @ 2014-09-11 16:35 ` Gabriel L. Somlo 2014-09-11 16:40 ` Paolo Bonzini 0 siblings, 1 reply; 37+ messages in thread From: Gabriel L. Somlo @ 2014-09-11 16:35 UTC (permalink / raw) To: Paolo Bonzini; +Cc: edk2-devel, agraf, qemu-devel, kraxel, reza.jelveh, lersek 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... :) > ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse 2014-09-11 16:35 ` Gabriel L. Somlo @ 2014-09-11 16:40 ` Paolo Bonzini 2014-09-11 17:11 ` Gabriel L. Somlo 2014-09-11 20:16 ` [Qemu-devel] " Gabriel L. Somlo 0 siblings, 2 replies; 37+ messages in thread From: Paolo Bonzini @ 2014-09-11 16:40 UTC (permalink / raw) To: Gabriel L. Somlo Cc: edk2-devel, agraf, qemu-devel, kraxel, reza.jelveh, lersek 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse 2014-09-11 16:40 ` Paolo Bonzini @ 2014-09-11 17:11 ` Gabriel L. Somlo 2014-09-11 17:15 ` [Qemu-devel] [edk2] " Paolo Bonzini 2014-09-11 20:16 ` [Qemu-devel] " Gabriel L. Somlo 1 sibling, 1 reply; 37+ messages in thread From: Gabriel L. Somlo @ 2014-09-11 17:11 UTC (permalink / raw) To: Paolo Bonzini; +Cc: edk2-devel, agraf, qemu-devel, kraxel, reza.jelveh, lersek 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. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Qemu-devel] [edk2] OVMF, Q35 and USB keyboard/mouse 2014-09-11 17:11 ` Gabriel L. Somlo @ 2014-09-11 17:15 ` Paolo Bonzini 0 siblings, 0 replies; 37+ messages in thread From: Paolo Bonzini @ 2014-09-11 17:15 UTC (permalink / raw) To: edk2-devel; +Cc: qemu-devel 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 > ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse 2014-09-11 16:40 ` Paolo Bonzini 2014-09-11 17:11 ` Gabriel L. Somlo @ 2014-09-11 20:16 ` Gabriel L. Somlo 2014-09-11 20:46 ` Laszlo Ersek 2014-09-12 6:46 ` Gerd Hoffmann 1 sibling, 2 replies; 37+ messages in thread From: Gabriel L. Somlo @ 2014-09-11 20:16 UTC (permalink / raw) To: Paolo Bonzini; +Cc: edk2-devel, agraf, qemu-devel, kraxel, reza.jelveh, lersek 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse 2014-09-11 20:16 ` [Qemu-devel] " Gabriel L. Somlo @ 2014-09-11 20:46 ` Laszlo Ersek 2014-09-11 21:34 ` Alexander Graf 2014-09-12 6:46 ` Gerd Hoffmann 1 sibling, 1 reply; 37+ messages in thread From: Laszlo Ersek @ 2014-09-11 20:46 UTC (permalink / raw) To: Gabriel L. Somlo, Paolo Bonzini Cc: agraf, reza.jelveh, edk2-devel, qemu-devel, kraxel 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse 2014-09-11 20:46 ` Laszlo Ersek @ 2014-09-11 21:34 ` Alexander Graf 2014-09-11 23:21 ` Gabriel L. Somlo 0 siblings, 1 reply; 37+ messages in thread From: Alexander Graf @ 2014-09-11 21:34 UTC (permalink / raw) To: Laszlo Ersek Cc: edk2-devel, qemu-devel, Gabriel L. Somlo, kraxel, reza.jelveh, Paolo Bonzini > 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse 2014-09-11 21:34 ` Alexander Graf @ 2014-09-11 23:21 ` Gabriel L. Somlo 2014-09-12 9:17 ` BALATON Zoltan 0 siblings, 1 reply; 37+ messages in thread From: Gabriel L. Somlo @ 2014-09-11 23:21 UTC (permalink / raw) To: Alexander Graf Cc: edk2-devel, qemu-devel, kraxel, reza.jelveh, Paolo Bonzini, Laszlo Ersek 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse 2014-09-11 23:21 ` Gabriel L. Somlo @ 2014-09-12 9:17 ` BALATON Zoltan 2014-09-12 17:58 ` Gabriel L. Somlo 0 siblings, 1 reply; 37+ messages in thread From: BALATON Zoltan @ 2014-09-12 9:17 UTC (permalink / raw) To: Gabriel L. Somlo Cc: edk2-devel, Alexander Graf, qemu-devel, kraxel, reza.jelveh, Paolo Bonzini, Laszlo Ersek 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse 2014-09-12 9:17 ` BALATON Zoltan @ 2014-09-12 17:58 ` Gabriel L. Somlo 0 siblings, 0 replies; 37+ messages in thread From: Gabriel L. Somlo @ 2014-09-12 17:58 UTC (permalink / raw) To: BALATON Zoltan Cc: edk2-devel, Alexander Graf, qemu-devel, kraxel, reza.jelveh, Paolo Bonzini, Laszlo Ersek 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse 2014-09-11 20:16 ` [Qemu-devel] " Gabriel L. Somlo 2014-09-11 20:46 ` Laszlo Ersek @ 2014-09-12 6:46 ` Gerd Hoffmann 2014-09-12 18:18 ` Gabriel L. Somlo 1 sibling, 1 reply; 37+ messages in thread From: Gerd Hoffmann @ 2014-09-12 6:46 UTC (permalink / raw) To: Gabriel L. Somlo Cc: edk2-devel, qemu-devel, agraf, reza.jelveh, Paolo Bonzini, lersek 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse 2014-09-12 6:46 ` Gerd Hoffmann @ 2014-09-12 18:18 ` Gabriel L. Somlo 2014-09-12 18:26 ` Paolo Bonzini 0 siblings, 1 reply; 37+ messages in thread From: Gabriel L. Somlo @ 2014-09-12 18:18 UTC (permalink / raw) To: Gerd Hoffmann Cc: edk2-devel, qemu-devel, agraf, reza.jelveh, Paolo Bonzini, lersek 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse 2014-09-12 18:18 ` Gabriel L. Somlo @ 2014-09-12 18:26 ` Paolo Bonzini 2014-09-12 19:59 ` Gabriel L. Somlo 0 siblings, 1 reply; 37+ messages in thread From: Paolo Bonzini @ 2014-09-12 18:26 UTC (permalink / raw) To: Gabriel L. Somlo, Gerd Hoffmann Cc: reza.jelveh, edk2-devel, lersek, qemu-devel, agraf 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse 2014-09-12 18:26 ` Paolo Bonzini @ 2014-09-12 19:59 ` Gabriel L. Somlo 2014-09-13 5:06 ` Laszlo Ersek 2014-09-15 14:50 ` Gabriel L. Somlo 0 siblings, 2 replies; 37+ messages in thread From: Gabriel L. Somlo @ 2014-09-12 19:59 UTC (permalink / raw) To: Paolo Bonzini Cc: edk2-devel, agraf, qemu-devel, Gerd Hoffmann, reza.jelveh, lersek 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse 2014-09-12 19:59 ` Gabriel L. Somlo @ 2014-09-13 5:06 ` Laszlo Ersek 2014-09-15 14:50 ` Gabriel L. Somlo 1 sibling, 0 replies; 37+ messages in thread From: Laszlo Ersek @ 2014-09-13 5:06 UTC (permalink / raw) To: Gabriel L. Somlo, Paolo Bonzini Cc: agraf, reza.jelveh, edk2-devel, Gerd Hoffmann, qemu-devel 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse 2014-09-12 19:59 ` Gabriel L. Somlo 2014-09-13 5:06 ` Laszlo Ersek @ 2014-09-15 14:50 ` Gabriel L. Somlo 2014-09-15 15:01 ` Laszlo Ersek 1 sibling, 1 reply; 37+ messages in thread From: Gabriel L. Somlo @ 2014-09-15 14:50 UTC (permalink / raw) To: Paolo Bonzini Cc: edk2-devel, agraf, qemu-devel, Gerd Hoffmann, reza.jelveh, lersek 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 ^ permalink raw reply related [flat|nested] 37+ messages in thread
* Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse 2014-09-15 14:50 ` Gabriel L. Somlo @ 2014-09-15 15:01 ` Laszlo Ersek 2014-09-15 15:07 ` Gabriel L. Somlo 0 siblings, 1 reply; 37+ messages in thread From: Laszlo Ersek @ 2014-09-15 15:01 UTC (permalink / raw) To: Gabriel L. Somlo, Paolo Bonzini Cc: agraf, reza.jelveh, edk2-devel, Gerd Hoffmann, qemu-devel 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse 2014-09-15 15:01 ` Laszlo Ersek @ 2014-09-15 15:07 ` Gabriel L. Somlo 2014-09-15 18:02 ` Laszlo Ersek 0 siblings, 1 reply; 37+ messages in thread From: Gabriel L. Somlo @ 2014-09-15 15:07 UTC (permalink / raw) To: Laszlo Ersek Cc: edk2-devel, agraf, qemu-devel, Gerd Hoffmann, reza.jelveh, Paolo Bonzini 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 ^ permalink raw reply related [flat|nested] 37+ messages in thread
* Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse 2014-09-15 15:07 ` Gabriel L. Somlo @ 2014-09-15 18:02 ` Laszlo Ersek 2014-09-15 19:23 ` Gabriel L. Somlo 2014-09-21 22:10 ` Gabriel L. Somlo 0 siblings, 2 replies; 37+ messages in thread From: Laszlo Ersek @ 2014-09-15 18:02 UTC (permalink / raw) To: Gabriel L. Somlo Cc: edk2-devel, agraf, qemu-devel, Gerd Hoffmann, reza.jelveh, Paolo Bonzini 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 > ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse 2014-09-15 18:02 ` Laszlo Ersek @ 2014-09-15 19:23 ` Gabriel L. Somlo 2014-09-15 19:56 ` BALATON Zoltan 2014-09-16 8:15 ` Gerd Hoffmann 2014-09-21 22:10 ` Gabriel L. Somlo 1 sibling, 2 replies; 37+ messages in thread From: Gabriel L. Somlo @ 2014-09-15 19:23 UTC (permalink / raw) To: Laszlo Ersek Cc: edk2-devel, agraf, qemu-devel, Gerd Hoffmann, reza.jelveh, Paolo Bonzini 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse 2014-09-15 19:23 ` Gabriel L. Somlo @ 2014-09-15 19:56 ` BALATON Zoltan 2014-09-16 8:15 ` Gerd Hoffmann 1 sibling, 0 replies; 37+ messages in thread From: BALATON Zoltan @ 2014-09-15 19:56 UTC (permalink / raw) To: Gabriel L. Somlo Cc: edk2-devel, agraf, qemu-devel, Gerd Hoffmann, reza.jelveh, Paolo Bonzini, Laszlo Ersek 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse 2014-09-15 19:23 ` Gabriel L. Somlo 2014-09-15 19:56 ` BALATON Zoltan @ 2014-09-16 8:15 ` Gerd Hoffmann 2014-09-21 20:00 ` Gabriel L. Somlo 1 sibling, 1 reply; 37+ messages in thread From: Gerd Hoffmann @ 2014-09-16 8:15 UTC (permalink / raw) To: Gabriel L. Somlo Cc: edk2-devel, agraf, qemu-devel, reza.jelveh, Paolo Bonzini, Laszlo Ersek 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse 2014-09-16 8:15 ` Gerd Hoffmann @ 2014-09-21 20:00 ` Gabriel L. Somlo 0 siblings, 0 replies; 37+ messages in thread From: Gabriel L. Somlo @ 2014-09-21 20:00 UTC (permalink / raw) To: Gerd Hoffmann Cc: edk2-devel, agraf, qemu-devel, reza.jelveh, Paolo Bonzini, Laszlo Ersek 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse 2014-09-15 18:02 ` Laszlo Ersek 2014-09-15 19:23 ` Gabriel L. Somlo @ 2014-09-21 22:10 ` Gabriel L. Somlo 2014-09-21 22:43 ` Laszlo Ersek 1 sibling, 1 reply; 37+ messages in thread From: Gabriel L. Somlo @ 2014-09-21 22:10 UTC (permalink / raw) To: Laszlo Ersek Cc: edk2-devel, agraf, qemu-devel, Gerd Hoffmann, reza.jelveh, Paolo Bonzini 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse 2014-09-21 22:10 ` Gabriel L. Somlo @ 2014-09-21 22:43 ` Laszlo Ersek 2014-09-22 16:44 ` [Qemu-devel] [edk2] " Paolo Bonzini 0 siblings, 1 reply; 37+ messages in thread From: Laszlo Ersek @ 2014-09-21 22:43 UTC (permalink / raw) To: Gabriel L. Somlo Cc: edk2-devel, agraf, qemu-devel, Gerd Hoffmann, reza.jelveh, Paolo Bonzini 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Qemu-devel] [edk2] OVMF, Q35 and USB keyboard/mouse 2014-09-21 22:43 ` Laszlo Ersek @ 2014-09-22 16:44 ` Paolo Bonzini 2014-09-22 16:59 ` Gabriel L. Somlo 2014-09-22 20:40 ` Laszlo Ersek 0 siblings, 2 replies; 37+ messages in thread From: Paolo Bonzini @ 2014-09-22 16:44 UTC (permalink / raw) To: edk2-devel, Gabriel L. Somlo; +Cc: qemu-devel 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Qemu-devel] [edk2] OVMF, Q35 and USB keyboard/mouse 2014-09-22 16:44 ` [Qemu-devel] [edk2] " Paolo Bonzini @ 2014-09-22 16:59 ` Gabriel L. Somlo 2014-09-22 20:40 ` Laszlo Ersek 1 sibling, 0 replies; 37+ messages in thread From: Gabriel L. Somlo @ 2014-09-22 16:59 UTC (permalink / raw) To: Paolo Bonzini; +Cc: edk2-devel, lersek, qemu-devel 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Qemu-devel] [edk2] OVMF, Q35 and USB keyboard/mouse 2014-09-22 16:44 ` [Qemu-devel] [edk2] " Paolo Bonzini 2014-09-22 16:59 ` Gabriel L. Somlo @ 2014-09-22 20:40 ` Laszlo Ersek 2014-09-24 22:03 ` Gabriel L. Somlo 1 sibling, 1 reply; 37+ messages in thread From: Laszlo Ersek @ 2014-09-22 20:40 UTC (permalink / raw) To: edk2-devel, Gabriel L. Somlo; +Cc: qemu-devel 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [Qemu-devel] [edk2] OVMF, Q35 and USB keyboard/mouse 2014-09-22 20:40 ` Laszlo Ersek @ 2014-09-24 22:03 ` Gabriel L. Somlo 0 siblings, 0 replies; 37+ messages in thread From: Gabriel L. Somlo @ 2014-09-24 22:03 UTC (permalink / raw) To: Laszlo Ersek, bonzini, kraxel; +Cc: edk2-devel, qemu-devel 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); } ^ permalink raw reply related [flat|nested] 37+ messages in thread
end of thread, other threads:[~2014-09-24 22:11 UTC | newest] Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-09-09 22:00 [Qemu-devel] OVMF, Q35 and USB keyboard/mouse Gabriel L. Somlo 2014-09-10 0:40 ` Laszlo Ersek 2014-09-10 6:31 ` Gerd Hoffmann 2014-09-10 7:59 ` Laszlo Ersek 2014-09-10 14:06 ` Gabriel L. Somlo 2014-09-10 23:08 ` [Qemu-devel] [edk2] " Paolo Bonzini 2014-09-11 15:42 ` [Qemu-devel] " Gabriel L. Somlo 2014-09-11 15:49 ` Paolo Bonzini 2014-09-11 16:35 ` Gabriel L. Somlo 2014-09-11 16:40 ` Paolo Bonzini 2014-09-11 17:11 ` Gabriel L. Somlo 2014-09-11 17:15 ` [Qemu-devel] [edk2] " Paolo Bonzini 2014-09-11 20:16 ` [Qemu-devel] " Gabriel L. Somlo 2014-09-11 20:46 ` Laszlo Ersek 2014-09-11 21:34 ` Alexander Graf 2014-09-11 23:21 ` Gabriel L. Somlo 2014-09-12 9:17 ` BALATON Zoltan 2014-09-12 17:58 ` Gabriel L. Somlo 2014-09-12 6:46 ` Gerd Hoffmann 2014-09-12 18:18 ` Gabriel L. Somlo 2014-09-12 18:26 ` Paolo Bonzini 2014-09-12 19:59 ` Gabriel L. Somlo 2014-09-13 5:06 ` Laszlo Ersek 2014-09-15 14:50 ` Gabriel L. Somlo 2014-09-15 15:01 ` Laszlo Ersek 2014-09-15 15:07 ` Gabriel L. Somlo 2014-09-15 18:02 ` Laszlo Ersek 2014-09-15 19:23 ` Gabriel L. Somlo 2014-09-15 19:56 ` BALATON Zoltan 2014-09-16 8:15 ` Gerd Hoffmann 2014-09-21 20:00 ` Gabriel L. Somlo 2014-09-21 22:10 ` Gabriel L. Somlo 2014-09-21 22:43 ` Laszlo Ersek 2014-09-22 16:44 ` [Qemu-devel] [edk2] " Paolo Bonzini 2014-09-22 16:59 ` Gabriel L. Somlo 2014-09-22 20:40 ` Laszlo Ersek 2014-09-24 22:03 ` Gabriel L. Somlo
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.