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) + } + } } }