Changing the hpet resource template appears to break WinXP, so revert the change.
Signed-off-by: Kevin O'Connor kevin@koconnor.net --- src/acpi-dsdt-hpet.dsl | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/src/acpi-dsdt-hpet.dsl b/src/acpi-dsdt-hpet.dsl index d5aa3f1..75b8a16 100644 --- a/src/acpi-dsdt-hpet.dsl +++ b/src/acpi-dsdt-hpet.dsl @@ -24,11 +24,15 @@ Scope(_SB) { Return (0x0F) } Name(_CRS, ResourceTemplate() { - IRQNoFlags() {2, 8} - Memory32Fixed(ReadOnly, - 0xFED00000, // Address Base - 0x00000400, // Address Length - ) + DWordMemory( + ResourceConsumer, PosDecode, MinFixed, MaxFixed, + NonCacheable, ReadWrite, + 0x00000000, + 0xFED00000, + 0xFED003FF, + 0x00000000, + 0x00000400 /* 1K memory: FED00000 - FED003FF */ + ) }) } }
On 12/05/12 23:36, Kevin O'Connor wrote:
Changing the hpet resource template appears to break WinXP, so revert the change.
Signed-off-by: Kevin O'Connor kevin@koconnor.net
src/acpi-dsdt-hpet.dsl | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/src/acpi-dsdt-hpet.dsl b/src/acpi-dsdt-hpet.dsl index d5aa3f1..75b8a16 100644 --- a/src/acpi-dsdt-hpet.dsl +++ b/src/acpi-dsdt-hpet.dsl @@ -24,11 +24,15 @@ Scope(_SB) { Return (0x0F) } Name(_CRS, ResourceTemplate() {
IRQNoFlags() {2, 8}
Kicking off this line is enougth to make winxp boot.
The irq logic in patch 2/3 works with winxp too, when booted with -no-hpet device manager shows irq being assigned to rtc, otherwise rtc has the ioports only. So there is no conflict for IRQ 8, /me wonders why winxp bsods nevertheless.
I think it's better to just comment out the line and add a comment why it is commented out.
cheers, Gerd
On Thu, Dec 06, 2012 at 09:42:19AM +0100, Gerd Hoffmann wrote:
On 12/05/12 23:36, Kevin O'Connor wrote:
Changing the hpet resource template appears to break WinXP, so revert the change.
Signed-off-by: Kevin O'Connor kevin@koconnor.net
src/acpi-dsdt-hpet.dsl | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/src/acpi-dsdt-hpet.dsl b/src/acpi-dsdt-hpet.dsl index d5aa3f1..75b8a16 100644 --- a/src/acpi-dsdt-hpet.dsl +++ b/src/acpi-dsdt-hpet.dsl @@ -24,11 +24,15 @@ Scope(_SB) { Return (0x0F) } Name(_CRS, ResourceTemplate() {
IRQNoFlags() {2, 8}Kicking off this line is enougth to make winxp boot.
The irq logic in patch 2/3 works with winxp too, when booted with -no-hpet device manager shows irq being assigned to rtc, otherwise rtc has the ioports only. So there is no conflict for IRQ 8, /me wonders why winxp bsods nevertheless.
I think it's better to just comment out the line and add a comment why it is commented out.
Feel free to send a different patch in place of this one.
If IRQ 8 isn't assigned to the HPET, is patch 2 still needed?
-Kevin
On Thu, Dec 06, 2012 at 04:48:56PM +0100, Gerd Hoffmann wrote:
Hi,
Feel free to send a different patch in place of this one.
Done.
Thanks - I pushed your patch (along with my "patch 1").
If IRQ 8 isn't assigned to the HPET, is patch 2 still needed?
No, but it doesn't hurt.
I'm going to hold off on that patch then until we have a better understanding of what is occurring.
-Kevin
On Wed, Dec 05, 2012 at 05:31:25PM -0500, Kevin O'Connor wrote:
Thanks. It looks like ConcatenateResTemplate wasn't in the ACPI 1.0 spec, so I think we should try to avoid using it. (I know it's used by the 64bit PCI code, but any machine supporting 64bit PCI is likely to have a more recent OS.)
I put together a slightly modified patch - see separate email.
...
Changing the hpet resource template appears to break WinXP, so revert the change.
Interestingly enough, even with the HPET _CRS reverted to its state before d9f5cdbdf, I get (with qemu git master, and with seabios git master plus the reverted hpet):
qemu-img create -f qcow2 xp.img bin/qemu-system-x86-64 -enable-kvm -m2048 -bios bios-master.bin \ -cdom ./XPSP2.iso -hda ./xp.img
A problem has been detected and Windows has been shut down... ... STOP: 0x7e (0xC0000005,0xf73b8d66,0xf7d1ea0,0xf78d1b9c) acpi.sys - address f73b8d66 base at f73ad000, datestamp 41107d27
I may be biased in favor of the d9f5cdbdf patch :) , but is there a chance removing/reapplying it is just tickling some other problem ?
Thanks, --Gabriel
On Thu, Dec 06, 2012 at 09:50:12AM -0500, Gabriel L. Somlo wrote:
On Wed, Dec 05, 2012 at 05:31:25PM -0500, Kevin O'Connor wrote:
Thanks. It looks like ConcatenateResTemplate wasn't in the ACPI 1.0 spec, so I think we should try to avoid using it. (I know it's used by the 64bit PCI code, but any machine supporting 64bit PCI is likely to have a more recent OS.)
I put together a slightly modified patch - see separate email.
...
Changing the hpet resource template appears to break WinXP, so revert the change.
Interestingly enough, even with the HPET _CRS reverted to its state before d9f5cdbdf, I get (with qemu git master, and with seabios git master plus the reverted hpet):
qemu-img create -f qcow2 xp.img bin/qemu-system-x86-64 -enable-kvm -m2048 -bios bios-master.bin \ -cdom ./XPSP2.iso -hda ./xp.img
A problem has been detected and Windows has been shut down... ... STOP: 0x7e (0xC0000005,0xf73b8d66,0xf7d1ea0,0xf78d1b9c) acpi.sys - address f73b8d66 base at f73ad000, datestamp 41107d27
I may be biased in favor of the d9f5cdbdf patch :) , but is there a chance removing/reapplying it is just tickling some other problem ?
I just retested, and it's reproducible for me. Keep in mind that these last three patches are not on master.
9600c800ac2a6b34a9993d99e7d3d4f7301e9265 - works d9f5cdbdf55d61aef9a1a534d9123ef734427478 - fails 7a53595a35fa76c9abb34fd9a73e5661a50aa6d6 (master) - fails master + this series 1/2/3 - works master + patch 3 - works
As before, if someone submits a fix, I'll use that instead of reverting.
-Kevin
On Thu, Dec 06, 2012 at 10:35:31AM -0500, Kevin O'Connor wrote:
I just retested, and it's reproducible for me. Keep in mind that these last three patches are not on master.
9600c800ac2a6b34a9993d99e7d3d4f7301e9265 - works d9f5cdbdf55d61aef9a1a534d9123ef734427478 - fails 7a53595a35fa76c9abb34fd9a73e5661a50aa6d6 (master) - fails master + this series 1/2/3 - works master + patch 3 - works
As before, if someone submits a fix, I'll use that instead of reverting.
I think I might have a fix, but with a caveat :)
I'm also using this on top of SeaBIOS git-master (for OS X):
diff --git a/src/acpi-dsdt-isa.dsl b/src/acpi-dsdt-isa.dsl index 23761db..daca850 100644 --- a/src/acpi-dsdt-isa.dsl +++ b/src/acpi-dsdt-isa.dsl @@ -1,6 +1,24 @@ /* Common legacy ISA style devices. */ Scope(_SB.PCI0.ISA) {
+ Device (SMC) { + Name (_HID, EisaId ("APP0001")) + Name (_CID, "smc-napa") + Method(_STA, 0) { + Return (0x0B) + } + Name (_CRS, ResourceTemplate () { + IO (Decode16, + 0x0300, // Range Minimum + 0x0300, // Range Maximum + 0x01, // Alignment + 0x20, // Length + ) + IRQNoFlags () + {6} + }) + } + Device(RTC) { Name(_HID, EisaId("PNP0B00")) Name(_CRS, ResourceTemplate() {
I haven't submitted it yet because I haven't figured out how to write a _STA method that didn't have to (unreliably, and, as Alex pointed out, dangerously) poke at SystemIO port space. However if I do the following in addition to the SMC above (using Gerd's earlier proposed RTC _CRS hack as an example):
diff --git a/src/acpi-dsdt-hpet.dsl b/src/acpi-dsdt-hpet.dsl index d5aa3f1..b6eb995 100644 --- a/src/acpi-dsdt-hpet.dsl +++ b/src/acpi-dsdt-hpet.dsl @@ -23,12 +23,23 @@ Scope(_SB) { } Return (0x0F) } - Name(_CRS, ResourceTemplate() { - IRQNoFlags() {2, 8} + Name(RESP, ResourceTemplate() { Memory32Fixed(ReadOnly, 0xFED00000, // Address Base 0x00000400, // Address Length ) }) + Name(RESI, ResourceTemplate() { + IRQNoFlags() {0, 8} + }) + Method(_CRS, 0) { + Store(_SB.PCI0.ISA.SMC._STA(), Local0) + If (LEqual(Local0, 0)) { + Return (RESP) + } else { + ConcatenateResTemplate(RESP, RESI, Local1) + Return (Local1) + } + } } }
Windows XP now works fine. If I hardcode the SMC._STA() to return 0 instead, XP still works (OS X obviously does not :)
If I could figure out how to write a reliable _STA method for the SMC, that would detect whether or not it was supplied as "-device applesmc" on the qemu command line, I think we might be on to something...
Thanks, --Gabriel
Hi,
Method(_CRS, 0) {Store(\_SB.PCI0.ISA.SMC._STA(), Local0)If (LEqual(Local0, 0)) {Return (RESP)} else {ConcatenateResTemplate(RESP, RESI, Local1)Return (Local1)}}}
Windows XP now works fine. If I hardcode the SMC._STA() to return 0 instead, XP still works (OS X obviously does not :)
Interesting.
If I could figure out how to write a reliable _STA method for the SMC, that would detect whether or not it was supplied as "-device applesmc" on the qemu command line, I think we might be on to something...
I've tried something simliar, but simply using the _STA method of the hpet. That somehow hints our hpet _STA method isn't working reliable on windows xp. I'll go to digg, but that has to wait until tomorrow.
cheers, Gerd
On Thu, Dec 06, 2012 at 06:07:20PM +0100, Gerd Hoffmann wrote:
If I could figure out how to write a reliable _STA method for the SMC, that would detect whether or not it was supplied as "-device applesmc" on the qemu command line, I think we might be on to something...
I've tried something simliar, but simply using the _STA method of the hpet. That somehow hints our hpet _STA method isn't working reliable on windows xp. I'll go to digg, but that has to wait until tomorrow.
Meanwhile, here's more iteration/datapoint: In the patch below, I'm checking for the *existence* of the SMC rather than attempting to evaluate its _STA. If it exists, we're on a "mac" and therefore should have IRQNoFlags. Otherwise, leave it out and make everyone else happy.
Although having a permanent SMC node and using its _STA method would be much nicer, if I ever figure out fw_cfg per Alex's sugestion :)
Thanks, --Gabriel
diff --git a/src/acpi-dsdt-hpet.dsl b/src/acpi-dsdt-hpet.dsl index d5aa3f1..9022027 100644 --- a/src/acpi-dsdt-hpet.dsl +++ b/src/acpi-dsdt-hpet.dsl @@ -23,12 +23,23 @@ Scope(_SB) { } Return (0x0F) } - Name(_CRS, ResourceTemplate() { - IRQNoFlags() {2, 8} + Name(RESP, ResourceTemplate() { Memory32Fixed(ReadOnly, 0xFED00000, // Address Base 0x00000400, // Address Length ) }) + Name(RESI, ResourceTemplate() { + IRQNoFlags() {0, 8} + }) + Method(_CRS, 0) { + If (CondRefOf(_SB.PCI0.ISA.SMC, Local0)) { + /* AppleSMC present, add IRQ resource */ + ConcatenateResTemplate(RESP, RESI, Local1) + Return (Local1) + } else { + Return (RESP) + } + } } } diff --git a/src/acpi-dsdt-isa.dsl b/src/acpi-dsdt-isa.dsl index 23761db..581edde 100644 --- a/src/acpi-dsdt-isa.dsl +++ b/src/acpi-dsdt-isa.dsl @@ -1,6 +1,17 @@ /* Common legacy ISA style devices. */ Scope(_SB.PCI0.ISA) {
+// Device (SMC) { +// Name(_HID, EisaId("APP0001")) +// Method(_STA, 0) { +// Return (0x0B) +// } +// Name (_CRS, ResourceTemplate () { +// IO (Decode16, 0x0300, 0x0300, 0x01, 0x20) +// IRQNoFlags() { 6 } +// }) +// } + Device(RTC) { Name(_HID, EisaId("PNP0B00")) Name(_CRS, ResourceTemplate() {
Hi,
If I could figure out how to write a reliable _STA method for the SMC, that would detect whether or not it was supplied as "-device applesmc" on the qemu command line, I think we might be on to something...
I've tried something simliar, but simply using the _STA method of the hpet. That somehow hints our hpet _STA method isn't working reliable on windows xp. I'll go to digg, but that has to wait until tomorrow.
Ahem, no. Even when taking the rtc out completely winxp still BSODs, looks like it has a check for irq8 hardcoded somewhere ...
cheers, Gerd
On 06.12.2012, at 17:36, Gabriel L. Somlo wrote:
On Thu, Dec 06, 2012 at 10:35:31AM -0500, Kevin O'Connor wrote:
I just retested, and it's reproducible for me. Keep in mind that these last three patches are not on master.
9600c800ac2a6b34a9993d99e7d3d4f7301e9265 - works d9f5cdbdf55d61aef9a1a534d9123ef734427478 - fails 7a53595a35fa76c9abb34fd9a73e5661a50aa6d6 (master) - fails master + this series 1/2/3 - works master + patch 3 - works
As before, if someone submits a fix, I'll use that instead of reverting.
I think I might have a fix, but with a caveat :)
I'm also using this on top of SeaBIOS git-master (for OS X):
diff --git a/src/acpi-dsdt-isa.dsl b/src/acpi-dsdt-isa.dsl index 23761db..daca850 100644 --- a/src/acpi-dsdt-isa.dsl +++ b/src/acpi-dsdt-isa.dsl @@ -1,6 +1,24 @@ /* Common legacy ISA style devices. */ Scope(_SB.PCI0.ISA) {
- Device (SMC) {
Name (_HID, EisaId ("APP0001"))Name (_CID, "smc-napa")Method(_STA, 0) {Return (0x0B)}Name (_CRS, ResourceTemplate () {IO (Decode16,0x0300, // Range Minimum0x0300, // Range Maximum0x01, // Alignment0x20, // Length)IRQNoFlags (){6}})- }
- Device(RTC) { Name(_HID, EisaId("PNP0B00")) Name(_CRS, ResourceTemplate() {
I haven't submitted it yet because I haven't figured out how to write a _STA method that didn't have to (unreliably, and, as Alex pointed out, dangerously) poke at SystemIO port space. However if I do the following in addition to the SMC above (using Gerd's earlier proposed RTC _CRS hack as an example):
diff --git a/src/acpi-dsdt-hpet.dsl b/src/acpi-dsdt-hpet.dsl index d5aa3f1..b6eb995 100644 --- a/src/acpi-dsdt-hpet.dsl +++ b/src/acpi-dsdt-hpet.dsl @@ -23,12 +23,23 @@ Scope(_SB) { } Return (0x0F) }
Name(_CRS, ResourceTemplate() {IRQNoFlags() {2, 8}
Name(RESP, ResourceTemplate() { Memory32Fixed(ReadOnly, 0xFED00000, // Address Base 0x00000400, // Address Length ) })Name(RESI, ResourceTemplate() {IRQNoFlags() {0, 8}})Method(_CRS, 0) {Store(\_SB.PCI0.ISA.SMC._STA(), Local0)If (LEqual(Local0, 0)) {Return (RESP)} else {ConcatenateResTemplate(RESP, RESI, Local1)Return (Local1)}}}
Windows XP now works fine. If I hardcode the SMC._STA() to return 0 instead, XP still works (OS X obviously does not :)
If I could figure out how to write a reliable _STA method for the SMC, that would detect whether or not it was supplied as "-device applesmc" on the qemu command line, I think we might be on to something...
You should be able to poke fw_cfg in the _STA method. The machine file could search its bus on init (or on machine create notify) and populate a fw_cfg variable to indicate whether it found an applesmc.
Alex
On Thu, Dec 06, 2012 at 06:10:46PM +0100, Alexander Graf wrote:
If I could figure out how to write a reliable _STA method for the SMC, that would detect whether or not it was supplied as "-device applesmc" on the qemu command line, I think we might be on to something...
You should be able to poke fw_cfg in the _STA method. The machine file could search its bus on init (or on machine create notify) and populate a fw_cfg variable to indicate whether it found an applesmc.
So the fw_cfg looks like this in 'info qtree':
dev: fw_cfg, id "" ctl_iobase = 0x510 data_iobase = 0x511 irq 0 mmio ffffffffffffffff/0000000000000002 mmio ffffffffffffffff/0000000000000001
I'm confused by the mmio values (start at the very top of memory, go for one or two bytes from there ?)
I also found this patch by Gerd, which doesn't seem to have made it upstream (yet):
http://www.mail-archive.com/qemu-devel@nongnu.org/msg110131.html
That patch suggests that I could just write stuff to 0x510 and read from 0x511, and if I get it "right" the values I read will end up making sense :)
Can anyone can point me to an example of how to interact with fw_cfg ?
Thanks, --Gabriel
On 06.12.2012, at 20:11, Gabriel L. Somlo wrote:
On Thu, Dec 06, 2012 at 06:10:46PM +0100, Alexander Graf wrote:
If I could figure out how to write a reliable _STA method for the SMC, that would detect whether or not it was supplied as "-device applesmc" on the qemu command line, I think we might be on to something...
You should be able to poke fw_cfg in the _STA method. The machine file could search its bus on init (or on machine create notify) and populate a fw_cfg variable to indicate whether it found an applesmc.
So the fw_cfg looks like this in 'info qtree':
dev: fw_cfg, id "" ctl_iobase = 0x510 data_iobase = 0x511 irq 0 mmio ffffffffffffffff/0000000000000002 mmio ffffffffffffffff/0000000000000001
I'm confused by the mmio values (start at the very top of memory, go for one or two bytes from there ?)
No idea what they're doing there. Just ignore them for now.
I also found this patch by Gerd, which doesn't seem to have made it upstream (yet):
http://www.mail-archive.com/qemu-devel@nongnu.org/msg110131.html
That patch suggests that I could just write stuff to 0x510 and read from 0x511, and if I get it "right" the values I read will end up making sense :)
Yup :). And the value could be the STA result.
Can anyone can point me to an example of how to interact with fw_cfg ?
Sure! Check out
http://git.qemu.org/?p=qemu.git;a=blob;f=pc-bios/optionrom/optionrom.h;h=3da...
Alex
On Thu, Dec 06, 2012 at 06:10:46PM +0100, Alexander Graf wrote:
You should be able to poke fw_cfg in the _STA method. The machine file could search its bus on init (or on machine create notify) and populate a fw_cfg variable to indicate whether it found an applesmc.
I don't think we should access fw_cfg from the AML code. AML code is already too fragile and I think accessing fw_cfg is just going to make it worse.
There are existing mechanisms for dynamically generating AML code (see the SeaBIOS SSDTs) and a way to pass parameters into the AML from SeaBIOS (see the BDAT code). Hopefully, this issue can be solved without requiring these mechanisms or an additional information passing mechanism.
-Kevin
On 12/06/12 21:56, Kevin O'Connor wrote:
On Thu, Dec 06, 2012 at 06:10:46PM +0100, Alexander Graf wrote:
You should be able to poke fw_cfg in the _STA method. The machine file could search its bus on init (or on machine create notify) and populate a fw_cfg variable to indicate whether it found an applesmc.
I don't think we should access fw_cfg from the AML code. AML code is already too fragile and I think accessing fw_cfg is just going to make it worse.
One can poke at the applesmc directly for detection ...
cheers, Gerd
On Fri, Dec 07, 2012 at 10:24:58AM +0100, Gerd Hoffmann wrote:
On 12/06/12 21:56, Kevin O'Connor wrote:
On Thu, Dec 06, 2012 at 06:10:46PM +0100, Alexander Graf wrote:
You should be able to poke fw_cfg in the _STA method. The machine file could search its bus on init (or on machine create notify) and populate a fw_cfg variable to indicate whether it found an applesmc.
I don't think we should access fw_cfg from the AML code. AML code is already too fragile and I think accessing fw_cfg is just going to make it worse.
One can poke at the applesmc directly for detection ...
We should return 0x0B on success, not 0x0F, though. --Gabriel
From baad5d90adae3d5de32bbf743996d4adb1e1ba18 Mon Sep 17 00:00:00 2001 From: Gerd Hoffmann kraxel@redhat.com Date: Fri, 7 Dec 2012 10:21:44 +0100 Subject: [PATCH] acpi: add apple smc device
Signed-off-by: Gerd Hoffmann kraxel@redhat.com
src/acpi-dsdt-isa.dsl | 22 ++++++++++++++++++++++ 1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/src/acpi-dsdt-isa.dsl b/src/acpi-dsdt-isa.dsl index 70e1e48..135c893 100644 --- a/src/acpi-dsdt-isa.dsl +++ b/src/acpi-dsdt-isa.dsl @@ -1,6 +1,28 @@ /* Common legacy ISA style devices. */ Scope(_SB.PCI0.ISA) {
- Device (SMC) {
Name(_HID, EisaId("APP0001"))OperationRegion(SMC, SystemIO, 0x0300, 0x20)Field(SMC, ByteAcc, NoLock, Preserve) {Offset(0x04),CMDP, 8,}Method(_STA, 0) {Store(0x10, CMDP) // APPLESMC_READ_CMDStore(CMDP, Local0)If (LEqual(Local0, 0x0c)) {Return (0x0F)} Else {Return (0x00)}}Name (_CRS, ResourceTemplate () {IO (Decode16, 0x0300, 0x0300, 0x01, 0x20)IRQNoFlags() { 6 }})- }
- Device(RTC) { Name(_HID, EisaId("PNP0B00")) Name(RESI, ResourceTemplate() {
-- 1.7.1
On Fri, Dec 07, 2012 at 10:26:48AM -0500, Gabriel L. Somlo wrote:
On Fri, Dec 07, 2012 at 10:24:58AM +0100, Gerd Hoffmann wrote:
On 12/06/12 21:56, Kevin O'Connor wrote:
On Thu, Dec 06, 2012 at 06:10:46PM +0100, Alexander Graf wrote:
You should be able to poke fw_cfg in the _STA method. The machine file could search its bus on init (or on machine create notify) and populate a fw_cfg variable to indicate whether it found an applesmc.
I don't think we should access fw_cfg from the AML code. AML code is already too fragile and I think accessing fw_cfg is just going to make it worse.
One can poke at the applesmc directly for detection ...
We should return 0x0B on success, not 0x0F, though.
Method(_STA, 0) {Store(0x10, CMDP) // APPLESMC_READ_CMDStore(CMDP, Local0)If (LEqual(Local0, 0x0c)) {
Also, once you've tickled the CMDP, the SMC internal state is no longer what OS X expects, so it gets all hung up on that later during the boot process. I guess I'll put "gain thorough understanding of the qemu applesmc state machine" on my ToDo list :)
--Gabriel
Method(_STA, 0) {Store(0x10, CMDP) // APPLESMC_READ_CMDStore(CMDP, Local0)If (LEqual(Local0, 0x0c)) {Also, once you've tickled the CMDP, the SMC internal state is no longer what OS X expects, so it gets all hung up on that later during the boot process. I guess I'll put "gain thorough understanding of the qemu applesmc state machine" on my ToDo list :)
_STA having side effects isn't exactly nice. Doing that once in _INI instead might work better.
cheers, Gerd
On Mon, Dec 10, 2012 at 08:04:11AM +0100, Gerd Hoffmann wrote:
Method(_STA, 0) {Store(0x10, CMDP) // APPLESMC_READ_CMDStore(CMDP, Local0)If (LEqual(Local0, 0x0c)) {Also, once you've tickled the CMDP, the SMC internal state is no longer what OS X expects, so it gets all hung up on that later during the boot process. I guess I'll put "gain thorough understanding of the qemu applesmc state machine" on my ToDo list :)
_STA having side effects isn't exactly nice. Doing that once in _INI instead might work better.
But _INI relies on _STA being evaluated first, so unless I'm missing something that'd be a catch-22 :(
So, I can think of a couple of alternatives:
1. have a SMC._STA() method that queries something
a) could be fw_cfg (may require hacking qemu/hw/applesmc.c *and* fw_cfg.c to make that happen)
b) could be the emulated SMC itself:
- right now, only the Data (0x300) and Command (0x304) ports are ever read/written, so we could set aside a magic qemu-smc-only "port" (e.g. 0x308, but anything within the 32-byte range should work) and have it always return a "magic" number when read (via a qemu/hw/applesmc.c patch);
_STA() could return 0xB if the magic number is there, or 0x0 otherwise
2. have a hardcoded SMC._STA() that always returns 0xB
a) This is where my ACPI n00b-ness starts to show. This would require somehow compiling the DSDT during QEMU startup, once we know whether '-device applesmc' was given on the qemu command line or not.
b) Kevin mentioned the SSDT and/or "BDAT" as other potential mechanisms to make something like this happen, but I'm not sure whether an SMC device node in the SSDT (as opposed to the DSDT) would be enough to "placate" OS X, aside from the (maybe simple) problem of figuring out how to control whether it gets included or not from the surrounding SeaBIOS and/or QEMU C code.
As for BDAT, grepping through the SeaBIOS source only gets me a few lines in acpi.c and acpi-dsdt-pci-crs.dsl, something related to an "operating region", not too clear how I'd get "there" from "here"...
Looking at the above, I think 1.b is my favorite, but then again, I may be wrong...
Any clue, advice, or feedback much appreciated !
--Gabriel
Hi,
But _INI relies on _STA being evaluated first, so unless I'm missing something that'd be a catch-22 :(
Oops, indeed.
So, I can think of a couple of alternatives:
have a SMC._STA() method that queries something
a) could be fw_cfg (may require hacking qemu/hw/applesmc.c *and* fw_cfg.c to make that happen)
I'd avoid fw_cfg if possible.
b) could be the emulated SMC itself: - right now, only the Data (0x300) and Command (0x304) ports are ever read/written, so we could set aside a magic qemu-smc-only "port" (e.g. 0x308, but anything within the 32-byte range should work) and have it always return a "magic" number when read (via a qemu/hw/applesmc.c patch);
Sounds sensible. Although the smc emulation in qemu looks incomplete, there are a bunch of #defines which are never ever used. Maybe a more complete emulation offers a way to detect the smc without side effects. Failing that some magic register looks ok to me. We should makes sure this doesn't conflict with anything the real hardware does though.
b) Kevin mentioned the SSDT and/or "BDAT" as other potential mechanisms to make something like this
I don't think this helps much. This just moves the smc detection from AML code to C code (and BDAT would be used to store the result in a way accessible from AML).
cheers, Gerd
On 11.12.2012, at 07:57, Gerd Hoffmann kraxel@redhat.com wrote:
Hi,
But _INI relies on _STA being evaluated first, so unless I'm missing something that'd be a catch-22 :(
Oops, indeed.
So, I can think of a couple of alternatives:
have a SMC._STA() method that queries something
a) could be fw_cfg (may require hacking qemu/hw/applesmc.c *and* fw_cfg.c to make that happen)
I'd avoid fw_cfg if possible.
b) could be the emulated SMC itself: - right now, only the Data (0x300) and Command (0x304) ports are ever read/written, so we could set aside a magic qemu-smc-only "port" (e.g. 0x308, but anything within the 32-byte range should work) and have it always return a "magic" number when read (via a qemu/hw/applesmc.c patch);Sounds sensible. Although the smc emulation in qemu looks incomplete, there are a bunch of #defines which are never ever used. Maybe a more complete emulation offers a way to detect the smc without side effects. Failing that some magic register looks ok to me. We should makes sure this doesn't conflict with anything the real hardware does though.
So what if SeaBIOS maps some PCI BAR to 0x300 with a device that goes wild if you write that detection sequence?
The whole point of a DSDT is to free the OS from probing devices.
Alex
b) Kevin mentioned the SSDT and/or "BDAT" as other potential mechanisms to make something like thisI don't think this helps much. This just moves the smc detection from AML code to C code (and BDAT would be used to store the result in a way accessible from AML).
cheers, Gerd
Hi,
Sounds sensible. Although the smc emulation in qemu looks incomplete, there are a bunch of #defines which are never ever used. Maybe a more complete emulation offers a way to detect the smc without side effects. Failing that some magic register looks ok to me. We should makes sure this doesn't conflict with anything the real hardware does though.
So what if SeaBIOS maps some PCI BAR to 0x300
It wouldn't.
The whole point of a DSDT is to free the OS from probing devices.
Or provide safe methods to probe devices.
For serial/parallel/floppy there are bits in the piix4/q35 chipset which indicate whenever those devices are present. We are using that, and this is actually similar to real hardware.
For the hpet we are accessing the hardware directly and checking for a valid vendor id to figure whenever the device is present or not (due to -no-hpet).
Assuming there is a side-effect free way to detect the applesmc I can't see what is wrong with using that. If we can't detect it without side effects we'll need a paravirtualized way to handle it. The options I see are:
(1) as suggested add a special detection register to our applesmc emulation. (2) find a spare bit in q35, next to the present bits for serial/parallel/floppy (osx wouldn't boot on piix4 anyway, so we don't have to care, right?) (3) use fw_cfg.
(1) + (2) are easy to handle from AML code.
cheers, Gerd
On 11.12.2012, at 09:21, Gerd Hoffmann kraxel@redhat.com wrote:
Hi,
Sounds sensible. Although the smc emulation in qemu looks incomplete, there are a bunch of #defines which are never ever used. Maybe a more complete emulation offers a way to detect the smc without side effects. Failing that some magic register looks ok to me. We should makes sure this doesn't conflict with anything the real hardware does though.
So what if SeaBIOS maps some PCI BAR to 0x300
It wouldn't.
The whole point of a DSDT is to free the OS from probing devices.
Or provide safe methods to probe devices.
For serial/parallel/floppy there are bits in the piix4/q35 chipset which indicate whenever those devices are present. We are using that, and this is actually similar to real hardware.
For the hpet we are accessing the hardware directly and checking for a valid vendor id to figure whenever the device is present or not (due to -no-hpet).
Assuming there is a side-effect free way to detect the applesmc I can't see what is wrong with using that. If we can't detect it without side effects we'll need a paravirtualized way to handle it. The options I see are:
(1) as suggested add a special detection register to our applesmc emulation.
This means we are different than real hw.
(2) find a spare bit in q35, next to the present bits for serial/parallel/floppy
Which means we differ from real hw -> bad.
(osx wouldn't boot on piix4 anyway, so we don't have to care, right?)
It could, but you need to manually add an lpc device. I don't think we really care about the piix4 case though :).
(3) use fw_cfg.
(1) + (2) are easy to handle from AML code.
Why if accessing fw_cfg harder than accessing the applesmc? Poking fw_cfg pios rather than applesmc pios shouldn't be an issue, right? After all, fw_cfg's purpose in life is to tell us details about the device model we can't easily find out otherwise.
Alex
cheers, Gerd
On Tue, Dec 11, 2012 at 09:33:21AM +0100, Alexander Graf wrote:
(1) as suggested add a special detection register to our applesmc emulation.
This means we are different than real hw.
(2) find a spare bit in q35, next to the present bits for serial/parallel/floppy
Which means we differ from real hw -> bad.
(osx wouldn't boot on piix4 anyway, so we don't have to care, right?)
It could, but you need to manually add an lpc device. I don't think we really care about the piix4 case though :).
(3) use fw_cfg.
(1) + (2) are easy to handle from AML code.
Why if accessing fw_cfg harder than accessing the applesmc? Poking fw_cfg pios rather than applesmc pios shouldn't be an issue, right? After all, fw_cfg's purpose in life is to tell us details about the device model we can't easily find out otherwise.
Normally, hardware either comes with an SMC or it doesn't. Therefore "real" SMC._STA() methods can get away with hardcoding a "return 0xB", or else they wouldn't be there to begin with :)
From this conversation it's becomming more and more clear to me that
inserting a SMC node into the SeaBIOS DSDT at VM creation time would be a lot more hacky and difficult than compiling it in permanently.
If we agree on this much, then a SeaBIOS SMC._STA() method would necessarily have to do some detection (since on QEMU '-device applesmc' is optional, and unlike on real hardware, we don't know if it's there until after the VM has started).
If I'm still on the right track so far, then it boils down to fw_cfg vs. a QemuSMC-specific "magic port".
The latter is dead simple to pull off :) but I see Alex's point about how that potentially exposes functionality that no OS would expect of a real AppleSMC (not that any real OS has any business poking any other ports besides 0x300 or 0x304). And we're talking read-only detection, definitely NOT writing anything to any I/O port(s) :)
I'll have another look at fw_cfg, and try to get a better idea of how much additional work that'd be...
What do you guys think ?
--Gabriel
On Tue, Dec 11, 2012 at 09:53:47AM -0500, Gabriel L. Somlo wrote:
On Tue, Dec 11, 2012 at 09:33:21AM +0100, Alexander Graf wrote:
(1) as suggested add a special detection register to our applesmc emulation.
This means we are different than real hw.
(2) find a spare bit in q35, next to the present bits for serial/parallel/floppy
Which means we differ from real hw -> bad.
(osx wouldn't boot on piix4 anyway, so we don't have to care, right?)
It could, but you need to manually add an lpc device. I don't think we really care about the piix4 case though :).
(3) use fw_cfg.
(1) + (2) are easy to handle from AML code.
[...]
What do you guys think ?
How about generating an SSDT with just the AppleSMC info in it, and then have qemu pass the SSDT into SeaBIOS using the existing ACPI table passing mechanism when the device is present.
-Kevin
On 12.12.2012, at 01:30, Kevin O'Connor wrote:
On Tue, Dec 11, 2012 at 09:53:47AM -0500, Gabriel L. Somlo wrote:
On Tue, Dec 11, 2012 at 09:33:21AM +0100, Alexander Graf wrote:
(1) as suggested add a special detection register to our applesmc emulation.
This means we are different than real hw.
(2) find a spare bit in q35, next to the present bits for serial/parallel/floppy
Which means we differ from real hw -> bad.
(osx wouldn't boot on piix4 anyway, so we don't have to care, right?)
It could, but you need to manually add an lpc device. I don't think we really care about the piix4 case though :).
(3) use fw_cfg.
(1) + (2) are easy to handle from AML code.
[...]
What do you guys think ?
How about generating an SSDT with just the AppleSMC info in it, and then have qemu pass the SSDT into SeaBIOS using the existing ACPI table passing mechanism when the device is present.
That would mean we move the present detection to SeaBIOS which also simply talks to fw_cfg. So it doesn't really buy us anything over an _STA function, does it?
Alex
On Wed, Dec 12, 2012 at 01:40:52AM +0100, Alexander Graf wrote:
On 12.12.2012, at 01:30, Kevin O'Connor wrote:
On Tue, Dec 11, 2012 at 09:53:47AM -0500, Gabriel L. Somlo wrote:
What do you guys think ?
How about generating an SSDT with just the AppleSMC info in it, and then have qemu pass the SSDT into SeaBIOS using the existing ACPI table passing mechanism when the device is present.
That would mean we move the present detection to SeaBIOS which also simply talks to fw_cfg. So it doesn't really buy us anything over an _STA function, does it?
QEMU can already pass an SSDT table to SeaBIOS - I was suggesting that QEMU could make the decision whether or not to send the table based on it's direct knowledge of whether or not the device is present.
There is, of course, complexities with this type of implementation too. However, I felt compelled to reiterate my desire for ACPI to be moved from SeaBIOS to QEMU as that's really the place that has all the knowledge to do it correctly.
-Kevin
On 12.12.2012, at 01:51, Kevin O'Connor wrote:
On Wed, Dec 12, 2012 at 01:40:52AM +0100, Alexander Graf wrote:
On 12.12.2012, at 01:30, Kevin O'Connor wrote:
On Tue, Dec 11, 2012 at 09:53:47AM -0500, Gabriel L. Somlo wrote:
What do you guys think ?
How about generating an SSDT with just the AppleSMC info in it, and then have qemu pass the SSDT into SeaBIOS using the existing ACPI table passing mechanism when the device is present.
That would mean we move the present detection to SeaBIOS which also simply talks to fw_cfg. So it doesn't really buy us anything over an _STA function, does it?
QEMU can already pass an SSDT table to SeaBIOS - I was suggesting that QEMU could make the decision whether or not to send the table based on it's direct knowledge of whether or not the device is present.
Another problem with the SSDT is that today it's mostly used for CPU nodes. So whether it works correctly with device nodes in a particular OS implementation is an open question.
There is, of course, complexities with this type of implementation too. However, I felt compelled to reiterate my desire for ACPI to be moved from SeaBIOS to QEMU as that's really the place that has all the knowledge to do it correctly.
I agree, the ideal case would be that QEMU assembles the DSDT on the fly, similar to how we do it for the fdt on e500 or the fdt on spapr. For the time being, I think doing an fw_cfg variable for whether we have an applesmc or not is a valid and safe solution though.
Alex
On Wed, Dec 12, 2012 at 01:59:36AM +0100, Alexander Graf wrote:
Another problem with the SSDT is that today it's mostly used for CPU nodes. So whether it works correctly with device nodes in a particular OS implementation is an open question.
All the PCI hotplug devices are sent via an SSDT in SeaBIOS today.
-Kevin
-
Alexander Graf -
Gabriel L. Somlo -
Gerd Hoffmann -
Kevin O'Connor