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

[Igor Mammedov <imammedo@redhat.com>]

On Fri, 17 Jan 2014 16:10:16 -0500
"Gabriel L. Somlo" <gsomlo@gmail.com> wrote:

> 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))
Isn't Local0 an optional?
Since it's not used for anything then just omit it.

> +            } else {
> +                Return (RESP)
> +            }
> +        }
>      }
>  }