From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48752) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5DZt-0002ud-Ak for qemu-devel@nongnu.org; Mon, 20 Jan 2014 07:03:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W5DZn-0007nN-Af for qemu-devel@nongnu.org; Mon, 20 Jan 2014 07:03:41 -0500 Received: from mx1.redhat.com ([209.132.183.28]:18336) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5DZn-0007nD-1U for qemu-devel@nongnu.org; Mon, 20 Jan 2014 07:03:35 -0500 Date: Mon, 20 Jan 2014 13:03:29 +0100 From: Igor Mammedov Message-ID: <20140120130329.3b5f6b8e@nial.usersys.redhat.com> In-Reply-To: <20140117211015.GB18752@ERROL.INI.CMU.EDU> References: <20140110171311.02e71f62@nial.usersys.redhat.com> <20140117211015.GB18752@ERROL.INI.CMU.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Gabriel L. Somlo" Cc: pbonzini@redhat.com, agraf@suse.de, lersek@redhat.com, qemu-devel@nongnu.org, mst@redhat.com On Fri, 17 Jan 2014 16:10:16 -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 > > 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) > + } > + } > } > }