[Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP

[Gabriel L. Somlo]

On Fri, Jan 10, 2014 at 05:13:11PM +0100, Igor Mammedov wrote:
> > On Fri, Jan 10, 2014 at 01:37:14PM +0100, Paolo Bonzini wrote:
> > > Il 09/01/2014 22:44, Gabriel L. Somlo ha scritto:
> > > > 1. hardcode "IRQNoFlags(){2, 8}" and require -no-hpet to prevent XP
> > > >    from bluescreening. Basically, this means we don't support XP on
> > > >    a VM where HPET is enabled.
> > > > 
> > > > 2. conditionally insert "IRQNoFlags(){2, 8}" if _OSI("Darwin") returns
> > > >    0xFFFFFFFF, [...] if we want to run OS X on piix+smp
> > > >    (all other combinations of (piix vs. q35) x (up vs.  smp) work fine
...
> there is harder route to get a clue why XP BSODs,
> one can use AMLI debugger to see what is happening in XP on boot
> http://msdn.microsoft.com/en-us/library/windows/hardware/ff537808%28v=vs.85%29.aspx
> that was how I found out about not supported ConcatenateResTemplate first.

After doing a bit of research, here's what I was able to find out:

1. "IRQNoFlags {2, 8}" was a mistake/typo I made early on, real Apple
   hardware (and *only* Apple hardware) has "IRQNoFlags {0, 8}" included
   with HPET._CRS

2. Both 0 and 8 are already spoken for, by the system timer (TMR), and
   by the RTC, respectively.

3. WinXP will also bluescreen on QEMU if HPET._CRS has "IRQNoFlags {0, 8}"
   added; in fact, it will bluescreen if *any* IRQNoFlags statement is
   included with the HPET DSDT node, as far as I was able to tell.

4. I acpidump-ed the DSDT on a bunch of machines, including a MacPro5,1,
   a MacBookPro2,2, a MacBookPro9,1, a Dell Latitude D630, and a Dell R410.
   Here's what I found:

     - All Macs (and only Macs) have IRQNoFlags {0, 8} in HPET._CRS.
     - my Dells (and I suspect most non-Apple machines) don't have
       IRQNoFlags in HPET_CRS at all.

     - On Macs, there's no TMR DSDT node at all.
     - My Latitude D630 laptop has a TMR node, with IRQNoFlags {2} in _CRS
     - the R410 also has a TMR node, with IRQNoFlags {0} in _CRS.

     - On Macs, RTC has no IRQNoFlags in its _CRS
     - Both my dells have IRQNoFlags {8} in RTC._CRS

5. I was able to boot XPsp2 on the MacBookPro2,2 straight from the DVD
   with a zeroed-out hard drive. It installs and works fine, and when
   I pull up the Device Manager, neither the RTC or the TMR devices have
   any IRQs listed under Properties/Resources.
   What is even more interesting, the HPET does NOT show up in the device
   tree *at all* !!!

6. On the MacBookPro9,1, XP bluescreens during install, in a similar
   mannner to how it bluescreens on QEMU if HPET._CRS contains IRQNoFlags.
   Bootcamp doesn't support anything older than Windows 7 on those machines,
   so I don't think there's anything I can do to get XP running and look
   at the device tree on that machine.

7. On QEMU, XP does indeed show the HPET alongside the TMR and RTC in
   its device tree, obviously without any IRQ resources under properties,
   since the only way it boots is if HPET._CRS doesn't include IRQNoFlags.

8. Windows 7, while it boots and runs fine when HPET._CRS contains
   IRQNoFlags, will show an unresolved IRQ conflict between the HPET and
   the RTC in the device tree. Commenting out IRQNoFlags from the RTC
   in QEMU does NOT solve that (still shows up as a conflict in the
   device tree).

9. I followed Igor's advice and ran a debug session, but unlike with
   ConcatenateResTemplate, XP didn't choke on AML byte code itself, but
   appears to die of a memory access violation:

     *** Fatal System Error: 0x0000007e (0x...)
     ...
     Probably caused by: ACPI.sys (ACPI!AcpiArbCrackPRT+113)

     80527bdc cc       int 3

   Poking around with various !amli debugger commands does not show
   anything AML-related as abnormal, so I think the problem is that
   either XP specifically expects the HPET._CRS buffer to be of a
   certain hardcoded size (which doesn't include any extra room for
   IRQNoFlags), or attempts to somehow process the values given via
   IRQNoFlags (0 and 8) in ways that cause it to then kill itself.

   Hard to tell without knowing more about XP internals (e.g., without
   XP kernel and/or acpi.sys source code).

At this point, conditionally inserting IRQNoFlags {0,8} only for OS X
sounds less of a hack and more like the right thing to do. I would be
comfortable using ConcatenateResTemplate since XP never gets a chance
to attempt to interpret that bytecode, which gets exercised only by
the _OSI("Darwin") branch. I tested this, and both XP and OSX seem
happy with it.

Please let me know what you think.

Thanks,
--Gabriel

diff --git a/hw/i386/acpi-dsdt-hpet.dsl b/hw/i386/acpi-dsdt-hpet.dsl
index dfde174..0cf7fbf 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(\_OSI("Darwin"), 0xFFFFFFFF)) {
+                Return (ConcatenateResTemplate(RESP, RESI, Local0))
+            } else {
+                Return (RESP)
+            }
+        }
     }
 }