[Qemu-devel] [PATCH] ACPI: Add IRQ resource to HPET._CRS on Mac OS X

[Gabriel L. Somlo]

Apple hardware invariably adds "IRQNoFlags() {0, 8}" to HPET._CRS,
and, at least on piix+smp, an OS X guest will panic unless IRQNoFlags
is present. On the other hand, Windows XP bluescreens whenever
IRQNoFlags is present. This patch conditionally includes IRQNoFlags
only when detecting the presence of an AppleSMC (as a heuristic
predictor for running a Mac OS X guest). Querying _OS and/or _OSI
directly was considered and rejected because such queries MAY NOT
be stateless from the OSPM standpoint, leading to potentially
unpredictable behavior.

Signed-off-by: Gabriel Somlo <address@hidden>
---

On Tue, Jan 21, 2014 at 01:38:26PM +0200, Michael S. Tsirkin wrote:
> So assuming people don't want to tie this to SMC
> (which I still like best) second best
> I like the idea of looking at the prefix of _OS -
> like code above does - then checking _OSI to make sure.
> This way this won't affect microsoft or linux guests.
> We probably call this in init though.
> Could you find out what are _OS values for OSX?
> 
> > It's just that all DSDTs I have access to (apple and dell) already do
> > call _OSI with impunity, so I'm not sure just how bad the voodoo is...
> 
> Not sure I trust what firmware developers do.  From what I saw they
> basically ship it and then software has to find work arounds.

So, after another closer look at the ACPI 5.0 spec, I indeed agree
that OSPM is allowed to maintain and alter state as a consequence of
being asked and replying to an _OSI("foo") query.

Which IMHO is bathshit insane: As a firmware dev, you CAN'T ask OSPM
a bunch of innocent yes/no questions and be confident it won't go off
doing crazy things just because you asked the wrong question in the
wrong order... :(

I had a look through the Linux source, and found that:

    1. The default answer to _OSI("Linux") is "false", as of 2.6.22

    2. The value of _OS is "Microsoft Windows NT". Yes, on Linux...

So, basically, the whole _OS* thing is treated as a joke. Well, not so
much a joke as a plea to the firmware to "Please Stop Trying To Help Me!" :)

No idea what OS X does, but at this point I think I thoroughly talked
myself out of wanting to use it, and tying HPET._CRS IRQNoFlags to the
return value of SMC._STA sounds like the less insane thing to do :)

Thanks,
  Gabriel

 hw/i386/acpi-dsdt-hpet.dsl | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/hw/i386/acpi-dsdt-hpet.dsl b/hw/i386/acpi-dsdt-hpet.dsl
index dfde174..bdc1370 100644
--- a/hw/i386/acpi-dsdt-hpet.dsl
+++ b/hw/i386/acpi-dsdt-hpet.dsl
@@ -38,14 +38,21 @@ Scope(\_SB) {
             }
             Return (0x0F)
         }
-        Name(_CRS, ResourceTemplate() {
-#if 0       /* This makes WinXP BSOD for not yet figured reasons. */
-            IRQNoFlags() {2, 8}
-#endif
+        Name(RESP, ResourceTemplate() {
             Memory32Fixed(ReadOnly,
                 0xFED00000,         // Address Base
                 0x00000400,         // Address Length
                 )
         })
+        Name(RESI, ResourceTemplate() {
+            IRQNoFlags() {0, 8}     // Mac OS X only
+        })
+        Method(_CRS, 0) {
+            If (LEqual(\_SB.PCI0.ISA.SMC._STA, 0x0B)) {
+                Return (ConcatenateResTemplate(RESP, RESI))
+            } Else {
+                Return (RESP)
+            }
+        }
     }
 }
-- 
1.8.1.4