[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP
From: |
Michael S. Tsirkin |
Subject: |
Re: [Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP |
Date: |
Mon, 20 Jan 2014 13:58:50 +0200 |
On Fri, Jan 17, 2014 at 04:10:16PM -0500, Gabriel L. Somlo 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
I think at this point I agree.
I think the hack looking for the SMC device is safer than _OSI: OSPMs
are known to do crazy things when they see _OSI, such as assuming they
need to try and emulate the OS probed.
> 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)
> + }
> + }
> }
> }
- Re: [Qemu-devel] [PATCH] Add option to disable FDC from ISA bus and ACPI on i386, (continued)
- Re: [Qemu-devel] [PATCH] Add option to disable FDC from ISA bus and ACPI on i386, Michael S. Tsirkin, 2014/01/08
- Re: [Qemu-devel] [PATCH] Add option to disable FDC from ISA bus and ACPI on i386, Gabriel L. Somlo, 2014/01/09
- Re: [Qemu-devel] [PATCH] Add option to disable FDC from ISA bus and ACPI on i386, Paolo Bonzini, 2014/01/09
- Re: [Qemu-devel] [PATCH] Add option to disable FDC from ISA bus and ACPI on i386, Michael S. Tsirkin, 2014/01/09
- Re: [Qemu-devel] [PATCH] Add option to disable FDC from ISA bus and ACPI on i386, Gabriel L. Somlo, 2014/01/09
- Re: [Qemu-devel] [PATCH] Add option to disable FDC from ISA bus and ACPI on i386, Gabriel L. Somlo, 2014/01/09
- Re: [Qemu-devel] [PATCH] Add option to disable FDC from ISA bus and ACPI on i386, Paolo Bonzini, 2014/01/10
- Re: [Qemu-devel] [PATCH] Add option to disable FDC from ISA bus and ACPI on i386, Gabriel L. Somlo, 2014/01/10
- Re: [Qemu-devel] [PATCH] Add option to disable FDC from ISA bus and ACPI on i386, Igor Mammedov, 2014/01/10
- [Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP, Gabriel L. Somlo, 2014/01/17
- Re: [Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP,
Michael S. Tsirkin <=
- Re: [Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP, Paolo Bonzini, 2014/01/20
- Re: [Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP, Michael S. Tsirkin, 2014/01/20
- Re: [Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP, Paolo Bonzini, 2014/01/20
- Re: [Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP, Gabriel L. Somlo, 2014/01/20
- Re: [Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP, Michael S. Tsirkin, 2014/01/20
- Re: [Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP, Gabriel L. Somlo, 2014/01/20
- Re: [Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP, Paolo Bonzini, 2014/01/21
- Re: [Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP, Michael S. Tsirkin, 2014/01/21
- Re: [Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP, Paolo Bonzini, 2014/01/21
- Re: [Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP, Michael S. Tsirkin, 2014/01/21