| Message ID | 20140108233924.GA11234@foober.ini.cmu.edu |
|---|---|
| State | New |
| Headers | show |
On 09.01.2014, at 00:39, Gabriel L. Somlo <gsomlo@gmail.com> wrote: > On Wed, Jan 08, 2014 at 11:13:54PM +0100, Paolo Bonzini wrote: >> Have you played with the HPET device? It would be nice to have Mac OS X >> support in QEMU 2.0. > > I remember telling you that the HPET needed an extra ACPI patch > (enclosed again below for reference) to work with OS X, and that > this patch conflicts with XP. > > In the mean time, after some tinkering, it turns out that Q35 works > fine without the patch. On PIIX, xnu crashes during boot with a "no > HPET found" panic unless the patch is applied. > > At this point, I'm tempted to just write off PIIX + OS X and declare > Q35 as the only "supported" machine type, to keep things simple and > avoid complicating the HPET ACPI code with if/then/else logic that > depends on the return value of SMC._STA(), etc. I think that's a great idea :). > Let me know what you all think. > > Thanks, > --Gabriel > > P.S. Another OS X issue is getting e1000 to "link up" (but in an earlier > conversation it was decided that guest-specific hacks belong in the BIOS > rather than in QEMU, so I still have a "todo" item to figure out where > to put that patch, and how :) Just put it straight into SeaBIOS :) Alex
On Wed, Jan 08, 2014 at 06:39:25PM -0500, Gabriel L. Somlo wrote: > On Wed, Jan 08, 2014 at 11:13:54PM +0100, Paolo Bonzini wrote: > > Have you played with the HPET device? It would be nice to have Mac OS X > > support in QEMU 2.0. > > I remember telling you that the HPET needed an extra ACPI patch > (enclosed again below for reference) to work with OS X, and that > this patch conflicts with XP. > > In the mean time, after some tinkering, it turns out that Q35 works > fine without the patch. On PIIX, xnu crashes during boot with a "no > HPET found" panic unless the patch is applied. > > At this point, I'm tempted to just write off PIIX + OS X and declare > Q35 as the only "supported" machine type, to keep things simple and > avoid complicating the HPET ACPI code with if/then/else logic that > depends on the return value of SMC._STA(), etc. > > Let me know what you all think. > > Thanks, > --Gabriel I still see reports of a bunch of issues with ahci so q35 is less stable at this point I think. I was hoping we can figure out a configuration that makes os x work without hurting xp *and* without just rudely detecting os x through the SMC._STA hack. > P.S. Another OS X issue is getting e1000 to "link up" (but in an earlier > conversation it was decided that guest-specific hacks belong in the BIOS > rather than in QEMU, so I still have a "todo" item to figure out where > to put that patch, and how :) > > ############################################################################### > # Modify DSDT entry for HPET: conditionally insert "IRQNoFlags() {2, 8}" into > # _CRS method only if an AppleSMC chip is present and enabled (otherwise, this > # will cause WinXP to BSOD). > # NOTE: not needed with q35, but necessary on piix !!! > ############################################################################### > diff --git a/hw/i386/acpi-dsdt-hpet.dsl b/hw/i386/acpi-dsdt-hpet.dsl > index dfde174..2a0158a 100644 > --- a/hw/i386/acpi-dsdt-hpet.dsl > +++ b/hw/i386/acpi-dsdt-hpet.dsl > @@ -38,14 +38,23 @@ 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() {2, 8} > + }) > + Method(_CRS, 0) { > + Store(\_SB.PCI0.ISA.SMC._STA, Local0) > + If (LEqual(Local0, 0x0B)) { // AppleSMC present, add IRQ > + ConcatenateResTemplate(RESP, RESI, Local1) > + Return (Local1) > + } else { > + Return (RESP) > + } > + } > } > }
On Thu, Jan 09, 2014 at 03:51:17AM +0200, Michael S. Tsirkin wrote: > I was hoping we can figure out a configuration that makes > os x work without hurting xp *and* without just rudely > detecting os x through the SMC._STA hack. Sadly, uncommenting "IRQNoFlags() {2, 8}" in HPET._CRS still causes XP to bluescreen. I've seen IRQNoFlags included with HPET._CRS on plenty instances of real hardware, so this must be some sort of second-order effect. The exact message on the XP bluescreen is: The BIOS in this system is not fully ACPI compliant. Please contact your system vendor or visit http://www.hardware-update.com for an updated BIOS. If you are unable to obtain an updated BIOS or the latest BIOS supplied by your vendor is not ACPI compliant, you can turn off ACPI mode during text mode setup. To do this, simply press the F7 key when you are prompted to install storage drivers. The system will not notify you that the F7 was pressed - it will silently disable ACPI and allow you to continue your installation. Technical information: *** STOP: 0x000000A5 (0x00010006,0x89A5D880,0x00000000,0x00000000) This while attempting to boot an image installed earlier, on a released version of QEMU, presumably with "functioning" ACPI. When booting from the XP-SP2 DVD, the bluescreen message read slightly different: Check to be sure you have adequate disk space. If a driver is identified in the Stop message, disable the driver or check with the manufacturer for driver updates. Try changing video adapters. Check with your hardware vendor for any BIOS updates. Disable BIOS memory options such as caching or shadowing. If you need to use Safe Mode to remove or disable components, restart your computer, press F8 to select Advanced Startup Options, and then select Safe Mode. Technical information: *** STOP: 0x0000007e (0xC0000005,0xF73B8D66,0xF78D1EA0,0xF78D1B9C) *** acpi.sys - Address F73B8D66 base at F73AD000, DateStamp 41107d27 But, following the tip in the *first* message (hitting F7 during install) gets me a working (if de-ACPI-fied) XP install. I don't know if/how to de-ACPI-fy an already installed XP disk image, but even if I did, that still feels "wrong". All this on piix (after uncommenting IRQNoFlags in HPET._CRS). With current/unchanged HPET._CRS, OS X boots fine (SnowLeopard only so far) on q35 in both smp and up mode, and -- I just figured this out -- on piix up only. When I try to boot SnowLeopard in smp on piix, I get an xnu hpet panic: panic(cpu 2 caller 0xffffff7f80864f8b): "No HPETs available...CPU(s) configured incorrectly\n"@/SourceCache/AppleIntelCPUPowerManagement/ AppleIntelCPUPowerManagement-142.6/pmThread.c:157 Debugger called:<panic> Whatever we do, we're not lying about ACPI convincingly enough, to either XP or OS X :) I'm relatively new to ACPI, so any other ideas on where to focus would be much appreciated ! Thanks, --Gabriel
Il 09/01/2014 19:51, Gabriel L. Somlo ha scritto: > panic(cpu 2 caller 0xffffff7f80864f8b): "No HPETs available...CPU(s) > configured > incorrectly\n"@/SourceCache/AppleIntelCPUPowerManagement/ > AppleIntelCPUPowerManagement-142.6/pmThread.c:157 > Debugger called:<panic> > > > Whatever we do, we're not lying about ACPI convincingly enough, to > either XP or OS X :) I'm relatively new to ACPI, so any other ideas > on where to focus would be much appreciated ! See http://lists.nongnu.org/archive/html/qemu-devel/2013-11/msg02815.html for some ideas. Paolo
On Thu, Jan 09, 2014 at 09:12:22PM +0100, Paolo Bonzini wrote: > Il 09/01/2014 19:51, Gabriel L. Somlo ha scritto: > > panic(cpu 2 caller 0xffffff7f80864f8b): "No HPETs available...CPU(s) > > configured > > incorrectly\n"@/SourceCache/AppleIntelCPUPowerManagement/ > > AppleIntelCPUPowerManagement-142.6/pmThread.c:157 > > Debugger called:<panic> > > > > > > Whatever we do, we're not lying about ACPI convincingly enough, to > > either XP or OS X :) I'm relatively new to ACPI, so any other ideas > > on where to focus would be much appreciated ! > > See > http://lists.nongnu.org/archive/html/qemu-devel/2013-11/msg02815.html > for some ideas. > > Paolo Except XP doesn't support ConcatenateResTemplate so need to write it differently.
Hi Paolo, On Thu, Jan 09, 2014 at 09:12:22PM +0100, Paolo Bonzini wrote: > See > http://lists.nongnu.org/archive/html/qemu-devel/2013-11/msg02815.html > for some ideas. I remember saving that email for a closer examination after I took care of the AppleSMC patch, and then I forgot all about it -- thanks for the reminder !!! Of the things you mentioned there: > The IRQNoFlags(){2,8} setting makes sense if the general configuration > register of the HPET has bits 0..1=1 (HPET enabled = 1 and HPET legacy > replacement route = 1). > > ... > > Method(_CRS, 0) { > Store(GCNF, Local0) > If (LEqual(LAnd(Local0, 3), 3)) { // Legacy replacement route > ConcatenateResTemplate(RESP, RESI, Local1) This made no difference. XP worked on piix with up and smp, and OS X worked everywhere *except* on piix+smp, where it crashed with an HPET panic. > (1) Does Mac OS work if you add a _PRS with IRQNoFlags and > Memory32Fixed, but leave _CRS as it is? Nope, same exact behavior. > (2) does it work with -no-hpet? With "IRQNoFlags(){2, 8}" hardcoded in HPET._CRS, XP appears to work great if -no-hpet is given. I guess _STA evaluates to 0, so nothing else matters. > (3) you could also make that dependent on _OSI("Darwin"). This works, for the same reason as querying SMC._STA (find something "unique" about OS X and conditionally insert IRQNoFlags(){2, 8}) if that "something" is detected.. So, we have two solutions that work: 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, which is only necessary if we want to run OS X on piix+smp (all other combinations of (piix vs. q35) x (up vs. smp) work fine already). I still don't get why on real hardware where the HPET has "IRQNoFlags(){2, 8}" in its _CRS method XP seems to be OK... Maybe there's some deeper, subtler ACPI "mismatch" we're triggering here... Thanks, --Gabriel
On Thu, Jan 09, 2014 at 11:33:59PM +0200, Michael S. Tsirkin wrote: > Except XP doesn't support ConcatenateResTemplate so need to write > it differently. I tried this: Device(HPET) { ... Field(HPTM, DWordAcc, Lock, Preserve) { VEND, 32, PRD, 32, UNUS, 32, GCNF, 32, } ... Name(CRS1, ResourceTemplate() { Memory32Fixed(ReadOnly, 0xFED00000, // Address Base 0x00000400, // Address Length ) }) Name(CRS2, ResourceTemplate() { IRQNoFlags() {2, 8} Memory32Fixed(ReadOnly, 0xFED00000, // Address Base 0x00000400, // Address Length ) }) Method(_CRS, 0) { Store(GCNF, Local0) If (LEqual(LAnd(Local0, 3), 3)) { // Legacy replacement route Return (CRS2) } else { Return (CRS1) } } } and got the same results. Besides, does it *really* matter? XP always takes the "else" branch, so it should never attempt to execute "ConcatenateResTemplate()" anyway. --Gabriel
Il 09/01/2014 22:44, Gabriel L. Somlo ha scritto: >> (1) Does Mac OS work if you add a _PRS with IRQNoFlags and >> Memory32Fixed, but leave _CRS as it is? > > Nope, same exact behavior. > >> (2) does it work with -no-hpet? > > With "IRQNoFlags(){2, 8}" hardcoded in HPET._CRS, XP appears to work > great if -no-hpet is given. I guess _STA evaluates to 0, so nothing > else matters. And what about Mac OS X? >> (3) you could also make that dependent on _OSI("Darwin"). > > This works, for the same reason as querying SMC._STA (find something > "unique" about OS X and conditionally insert IRQNoFlags(){2, 8}) if > that "something" is detected.. > > So, we have two solutions that work: > > 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, which is only necessary if we want to run OS X on piix+smp > (all other combinations of (piix vs. q35) x (up vs. smp) work fine > already). _OSI is bad, but (1) is worse. > I still don't get why on real hardware where the HPET has > "IRQNoFlags(){2, 8}" in its _CRS method XP seems to be OK... My laptop has this: Device (HPET) { Name (_HID, EisaId ("PNP0103")) // _HID: Hardware ID Method (_STA, 0, NotSerialized) // _STA: Status { If (LAnd (\WNTF, LNot (\WXPF))) { Return (0x00) } Else { Return (0x0F) } Return (0x00) } Name (BUF0, ResourceTemplate () { Memory32Fixed (ReadOnly, 0xFED00000, // Address Base 0x00000400, // Address Length _Y27) }) Method (_CRS, 0, Serialized) // _CRS: Current Resource Settings { CreateDWordField (BUF0, \_SB.PCI0.LPC.HPET._Y27._BAS, HPT0) // _BAS: Base Address Store (\HPET, HPT0) // HPET comes from a table that BIOS fills in reserved memory Return (BUF0) } } so no IRQs, and my workstation is similar. They are respectively from Lenovo and Fujitsu. Looks like an Apple quirk. Paolo
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, which is only necessary if we want to run OS X on piix+smp > > (all other combinations of (piix vs. q35) x (up vs. smp) work fine > > already). > > _OSI is bad, but (1) is worse. Agreed. > > I still don't get why on real hardware where the HPET has > > "IRQNoFlags(){2, 8}" in its _CRS method XP seems to be OK... > > My laptop has this: > > [...] > > Name (BUF0, ResourceTemplate () > { > Memory32Fixed (ReadOnly, > 0xFED00000, // Address Base > 0x00000400, // Address Length > _Y27) > }) > Method (_CRS, 0, Serialized) // _CRS: Current Resource Settings > { > CreateDWordField (BUF0, \_SB.PCI0.LPC.HPET._Y27._BAS, HPT0) // _BAS: Base Address > Store (\HPET, HPT0) // HPET comes from a table that BIOS fills in reserved memory > Return (BUF0) > } > } > > so no IRQs, and my workstation is similar. They are respectively from > Lenovo and Fujitsu. Looks like an Apple quirk. Hmmm, I could have sworn I saw IRQNoFlags on one of my old Dell laptops (Dell Latitude D630), but I just had another look and it's not there, so I was clearly misremembering that ! I think you're right, of all the hardware I currently have access to, only the various Apple machines have IRQNoFlags in HPET._CRS ! Given that, I'm starting to feel better and better about using _OSI(). Michael: regarding your comment about "ConcatenateResTemplate" not being supported by XP: Can I safely assume that as long as it's always on the branch NOT taken by XP, we're OK having it in there ? E.g., if _OSI("Darwin") then ConcatenateResTemplate... else stuff_that_XP_cares_about Once I have that sorted out, I'll send a patch. Thanks, --Gabriel
On Fri, 10 Jan 2014 10:35:14 -0500 "Gabriel L. Somlo" <gsomlo@gmail.com> 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, which is only necessary if we want to run OS X on piix+smp > > > (all other combinations of (piix vs. q35) x (up vs. smp) work fine > > > already). > > > > _OSI is bad, but (1) is worse. > > Agreed. > > > > I still don't get why on real hardware where the HPET has > > > "IRQNoFlags(){2, 8}" in its _CRS method XP seems to be OK... > > > > My laptop has this: > > > > [...] > > > > Name (BUF0, ResourceTemplate () > > { > > Memory32Fixed (ReadOnly, > > 0xFED00000, // Address Base > > 0x00000400, // Address Length > > _Y27) > > }) > > Method (_CRS, 0, Serialized) // _CRS: Current Resource Settings > > { > > CreateDWordField (BUF0, \_SB.PCI0.LPC.HPET._Y27._BAS, HPT0) // _BAS: Base Address > > Store (\HPET, HPT0) // HPET comes from a table that BIOS fills in reserved memory > > Return (BUF0) > > } > > } > > > > so no IRQs, and my workstation is similar. They are respectively from > > Lenovo and Fujitsu. Looks like an Apple quirk. > > Hmmm, I could have sworn I saw IRQNoFlags on one of my old Dell > laptops (Dell Latitude D630), but I just had another look and it's > not there, so I was clearly misremembering that ! > > I think you're right, of all the hardware I currently have access to, > only the various Apple machines have IRQNoFlags in HPET._CRS ! > > Given that, I'm starting to feel better and better about using _OSI(). > > Michael: regarding your comment about "ConcatenateResTemplate" not > being supported by XP: Can I safely assume that as long as it's always > on the branch NOT taken by XP, we're OK having it in there ? E.g., 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. > > if _OSI("Darwin") then > ConcatenateResTemplate... > else > stuff_that_XP_cares_about > > Once I have that sorted out, I'll send a patch. > > Thanks, > --Gabriel
diff --git a/hw/i386/acpi-dsdt-hpet.dsl b/hw/i386/acpi-dsdt-hpet.dsl index dfde174..2a0158a 100644 --- a/hw/i386/acpi-dsdt-hpet.dsl +++ b/hw/i386/acpi-dsdt-hpet.dsl @@ -38,14 +38,23 @@ 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() {2, 8} + }) + Method(_CRS, 0) { + Store(\_SB.PCI0.ISA.SMC._STA, Local0) + If (LEqual(Local0, 0x0B)) { // AppleSMC present, add IRQ + ConcatenateResTemplate(RESP, RESI, Local1) + Return (Local1) + } else { + Return (RESP) + } + } } }