| Message ID | AANLkTi=eRUHdL0wOL-ThAoDcu3v+e0kidaxXq-d9UsA=@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
On 23.11.2010, at 22:25, adq wrote: > This patch ups the APIC version from 0x11 to 0x14. After that Mac OS X > loads successfully (with appropriate kexts, applesmc ain't hooked up > properly yet I see unfortunately). AppleSMC emulation is upstream, but the ACPI entries are missing. Once you add those, all is fine. > According to to the Intel IA-32 Software Developers Manual Vol 3 page > 290, the version should be 0x14 Pentium 4/Xeon CPUs anyway. > > Signed-off-by: Andrew de Quincey <adq@lidskialf.net> > > diff --git a/hw/apic.c b/hw/apic.c > index 5f4a87c..20304e0 100644 > --- a/hw/apic.c > +++ b/hw/apic.c > @@ -704,7 +704,7 @@ static uint32_t apic_mem_readl(void *opaque, > target_phys_addr_t addr) > val = s->id << 24; > break; > case 0x03: /* version */ > - val = 0x11 | ((APIC_LVT_NB - 1) << 16); /* version 0x11 */ > + val = 0x14 | ((APIC_LVT_NB - 1) << 16); /* version 0x14 */ What exactly changed between the versions? Did new registers get introduced or subtle behavior change? Is there some proper documentation on the changed between the apic versions? Alex
On 23 November 2010 23:41, Alexander Graf <agraf@suse.de> wrote: > > On 23.11.2010, at 22:25, adq wrote: > >> This patch ups the APIC version from 0x11 to 0x14. After that Mac OS X >> loads successfully (with appropriate kexts, applesmc ain't hooked up >> properly yet I see unfortunately). >) > AppleSMC emulation is upstream, but the ACPI entries are missing. Once you add those, all is fine. Ah yeah, I've just this minute added the DSDT entry from your patch for the SMC device and it now works with the vanilla SMC driver. Nice work! It *is* annoying that IASL now erroneously(?) complains about the hypen in "Name (_CID, "smc-napa")" though. Adding the HPET DSDT data causes it to claim it can't support the hardware (and a zillion more DSDT errors); I'll have a play about with that (perhaps its just the new DSDT validation stuff).. I'm assuming we'll eventually be able to use the upcoming AHCI support instead of adding ICH drivers or hacking the PIIX kext's plist (I'm doing the latter). Note: the boot loader from your site unfortunately didn't work with SL - its just hangs loading the kernel. I'm successfully using the latest "boot" file extracted from Chameleon and supplying it to qemu with a "-kernel" parameter. >> According to to the Intel IA-32 Software Developers Manual Vol 3 page >> 290, the version should be 0x14 Pentium 4/Xeon CPUs anyway. >> >> Signed-off-by: Andrew de Quincey <adq@lidskialf.net> >> >> diff --git a/hw/apic.c b/hw/apic.c >> index 5f4a87c..20304e0 100644 >> --- a/hw/apic.c >> +++ b/hw/apic.c >> @@ -704,7 +704,7 @@ static uint32_t apic_mem_readl(void *opaque, >> target_phys_addr_t addr) >> val = s->id << 24; >> break; >> case 0x03: /* version */ >> - val = 0x11 | ((APIC_LVT_NB - 1) << 16); /* version 0x11 */ >> + val = 0x14 | ((APIC_LVT_NB - 1) << 16); /* version 0x14 */ > > What exactly changed between the versions? Did new registers get introduced or subtle behavior change? Is there some proper documentation on the changed between the apic versions? I've been trying to find out; I'm still searching intel's docs to find an 0x11 version to compare with :( The failure mode is that mac os X SL whines about the APIC being an unexpected version (0x11) and it wants 0x14 as a minimum.
On 24.11.2010, at 03:40, adq wrote: > On 23 November 2010 23:41, Alexander Graf <agraf@suse.de> wrote: >> >> On 23.11.2010, at 22:25, adq wrote: >> >>> This patch ups the APIC version from 0x11 to 0x14. After that Mac OS X >>> loads successfully (with appropriate kexts, applesmc ain't hooked up >>> properly yet I see unfortunately). >> ) >> AppleSMC emulation is upstream, but the ACPI entries are missing. Once you add those, all is fine. > > Ah yeah, I've just this minute added the DSDT entry from your patch > for the SMC device and it now works with the vanilla SMC driver. Nice > work! > > It *is* annoying that IASL now erroneously(?) complains about the > hypen in "Name (_CID, "smc-napa")" though. > > Adding the HPET DSDT data causes it to claim it can't support the > hardware (and a zillion more DSDT errors); I'll have a play about with > that (perhaps its just the new DSDT validation stuff).. Interesting. I was also thinking that maybe we can leverage overriding mechanisms that are already available. Maybe it's possible to squeeze the HPET node into an SSDT. Maybe we need to override the whole DSDT from the command line. > I'm assuming we'll eventually be able to use the upcoming AHCI support > instead of adding ICH drivers or hacking the PIIX kext's plist (I'm > doing the latter). That's the goal :). I haven't even tried to use it with osx yet though. If you feel adventurous, I'd love to hear if it works. > Note: the boot loader from your site unfortunately didn't work with SL > - its just hangs loading the kernel. I'm successfully using the latest > "boot" file extracted from Chameleon and supplying it to qemu with a > "-kernel" parameter. Yeah, I think I do have a version that loads SL successfully somewhere local back from the days when it wasn't released yet. But if recent Chmeleon can load it just fine, it's probably the way forward to just use that and rip out all the illegal and ugly parts. > >>> According to to the Intel IA-32 Software Developers Manual Vol 3 page >>> 290, the version should be 0x14 Pentium 4/Xeon CPUs anyway. >>> >>> Signed-off-by: Andrew de Quincey <adq@lidskialf.net> >>> >>> diff --git a/hw/apic.c b/hw/apic.c >>> index 5f4a87c..20304e0 100644 >>> --- a/hw/apic.c >>> +++ b/hw/apic.c >>> @@ -704,7 +704,7 @@ static uint32_t apic_mem_readl(void *opaque, >>> target_phys_addr_t addr) >>> val = s->id << 24; >>> break; >>> case 0x03: /* version */ >>> - val = 0x11 | ((APIC_LVT_NB - 1) << 16); /* version 0x11 */ >>> + val = 0x14 | ((APIC_LVT_NB - 1) << 16); /* version 0x14 */ >> >> What exactly changed between the versions? Did new registers get introduced or subtle behavior change? Is there some proper documentation on the changed between the apic versions? > > I've been trying to find out; I'm still searching intel's docs to find > an 0x11 version to compare with :( Please try very hard. I haven't found anything myself either yet, but without a spec it's hard to justify these changes upstream :(. > The failure mode is that mac os X SL whines about the APIC being an > unexpected version (0x11) and it wants 0x14 as a minimum. Yup, I remember that issue. To really make this all useful, we also need to change the numbers in KVM though. Alex
On 24 November 2010 11:00, Alexander Graf <agraf@suse.de> wrote: > > On 24.11.2010, at 03:40, adq wrote: > >> On 23 November 2010 23:41, Alexander Graf <agraf@suse.de> wrote: >>> >>> On 23.11.2010, at 22:25, adq wrote: >>> >>>> This patch ups the APIC version from 0x11 to 0x14. After that Mac OS X >>>> loads successfully (with appropriate kexts, applesmc ain't hooked up >>>> properly yet I see unfortunately). >>> ) >>> AppleSMC emulation is upstream, but the ACPI entries are missing. Once you add those, all is fine. >> >> Ah yeah, I've just this minute added the DSDT entry from your patch >> for the SMC device and it now works with the vanilla SMC driver. Nice >> work! >> >> It *is* annoying that IASL now erroneously(?) complains about the >> hypen in "Name (_CID, "smc-napa")" though. >> >> Adding the HPET DSDT data causes it to claim it can't support the >> hardware (and a zillion more DSDT errors); I'll have a play about with >> that (perhaps its just the new DSDT validation stuff).. > > Interesting. I was also thinking that maybe we can leverage overriding mechanisms that are already available. Maybe it's possible to squeeze the HPET node into an SSDT. Maybe we need to override the whole DSDT from the command line. We'll definitely need to override the DSDT for the applesmc device. I was thinking something along the lines of an additional DSDT binary supplied with QEMU for use when emulating apple hardware as you suggest. >> I'm assuming we'll eventually be able to use the upcoming AHCI support >> instead of adding ICH drivers or hacking the PIIX kext's plist (I'm >> doing the latter). > > That's the goal :). I haven't even tried to use it with osx yet though. If you feel adventurous, I'd love to hear if it works. > >> Note: the boot loader from your site unfortunately didn't work with SL >> - its just hangs loading the kernel. I'm successfully using the latest >> "boot" file extracted from Chameleon and supplying it to qemu with a >> "-kernel" parameter. > > Yeah, I think I do have a version that loads SL successfully somewhere local back from the days when it wasn't released yet. But if recent Chmeleon can load it just fine, it's probably the way forward to just use that and rip out all the illegal and ugly parts. > >> >>>> According to to the Intel IA-32 Software Developers Manual Vol 3 page >>>> 290, the version should be 0x14 Pentium 4/Xeon CPUs anyway. >>>> >>>> Signed-off-by: Andrew de Quincey <adq@lidskialf.net> >>>> >>>> diff --git a/hw/apic.c b/hw/apic.c >>>> index 5f4a87c..20304e0 100644 >>>> --- a/hw/apic.c >>>> +++ b/hw/apic.c >>>> @@ -704,7 +704,7 @@ static uint32_t apic_mem_readl(void *opaque, >>>> target_phys_addr_t addr) >>>> val = s->id << 24; >>>> break; >>>> case 0x03: /* version */ >>>> - val = 0x11 | ((APIC_LVT_NB - 1) << 16); /* version 0x11 */ >>>> + val = 0x14 | ((APIC_LVT_NB - 1) << 16); /* version 0x14 */ >>> >>> What exactly changed between the versions? Did new registers get introduced or subtle behavior change? Is there some proper documentation on the changed between the apic versions? >> >> I've been trying to find out; I'm still searching intel's docs to find >> an 0x11 version to compare with :( > > Please try very hard. I haven't found anything myself either yet, but without a spec it's hard to justify these changes upstream :(. > >> The failure mode is that mac os X SL whines about the APIC being an >> unexpected version (0x11) and it wants 0x14 as a minimum. > > Yup, I remember that issue. To really make this all useful, we also need to change the numbers in KVM though. Hi, I /think/ the 0x11 APIC version might be from the pentium pro era. However the only proof is this random dmesg trace I found at: http://www.sfires.net/evil/dmesg.txt "Processor #6 Pentium(tm) Pro APIC version 17" The Pentium Pro software manual vol 3 can be found here: http://www.biblio.deis.unibo.it/Testi_Liberi/Pentiumpro/PentiumPro_Vol3.pdf I've not had time to look at the registers contents in detail yet, but there are definitely a few new registers in the latest arch software manual from Intel. Incidentally, I just tried updating a VM to SL 10.6.5; it can boot darwin fine, but doesn't start the macosx GUI. Its the same behaviour as if the applesmc device is not present. It /does/ say "DSMOS has arrived", but there are a few other SMC-comms errors reported.
On Wed, Nov 24, 2010 at 02:08:16PM +0000, adq wrote: > > Interesting. I was also thinking that maybe we can leverage overriding mechanisms that are already available. Maybe it's possible to squeeze the HPET node into an SSDT. Maybe we need to override the whole DSDT from the command line. > > We'll definitely need to override the DSDT for the applesmc device. I > was thinking something along the lines of an additional DSDT binary > supplied with QEMU for use when emulating apple hardware as you > suggest. The patches for qemu and seabios have been floating around. I wrote them for Q35 chipset support, but no one has gotten interested in it. But now, you are there. I'm willing to rebase/resend them.
Am 24.11.2010 12:00, Alexander Graf wrote: >>>> According to to the Intel IA-32 Software Developers Manual Vol 3 page >>>> 290, the version should be 0x14 Pentium 4/Xeon CPUs anyway. >>>> >>>> Signed-off-by: Andrew de Quincey <adq@lidskialf.net> >>>> >>>> diff --git a/hw/apic.c b/hw/apic.c >>>> index 5f4a87c..20304e0 100644 >>>> --- a/hw/apic.c >>>> +++ b/hw/apic.c >>>> @@ -704,7 +704,7 @@ static uint32_t apic_mem_readl(void *opaque, >>>> target_phys_addr_t addr) >>>> val = s->id << 24; >>>> break; >>>> case 0x03: /* version */ >>>> - val = 0x11 | ((APIC_LVT_NB - 1) << 16); /* version 0x11 */ >>>> + val = 0x14 | ((APIC_LVT_NB - 1) << 16); /* version 0x14 */ >>> >>> What exactly changed between the versions? Did new registers get introduced or subtle behavior change? Is there some proper documentation on the changed between the apic versions? >> >> I've been trying to find out; I'm still searching intel's docs to find >> an 0x11 version to compare with :( > > Please try very hard. I haven't found anything myself either yet, but without a spec it's hard to justify these changes upstream :(. > >> The failure mode is that mac os X SL whines about the APIC being an >> unexpected version (0x11) and it wants 0x14 as a minimum. > > Yup, I remember that issue. To really make this all useful, we also need to change the numbers in KVM though. Also, the version has to be set depending on the emulated CPU (even more when there will be emulation differences). Jan
On 25 November 2010 11:28, Isaku Yamahata <yamahata@valinux.co.jp> wrote: > On Wed, Nov 24, 2010 at 02:08:16PM +0000, adq wrote: >> > Interesting. I was also thinking that maybe we can leverage overriding mechanisms that are already available. Maybe it's possible to squeeze the HPET node into an SSDT. Maybe we need to override the whole DSDT from the command line. >> >> We'll definitely need to override the DSDT for the applesmc device. I >> was thinking something along the lines of an additional DSDT binary >> supplied with QEMU for use when emulating apple hardware as you >> suggest. > > The patches for qemu and seabios have been floating around. > I wrote them for Q35 chipset support, but no one has gotten interested in it. > But now, you are there. I'm willing to rebase/resend them. I'd definitely be interested to see those!
On 24 November 2010 11:00, Alexander Graf <agraf@suse.de> wrote: > > On 24.11.2010, at 03:40, adq wrote: > >> On 23 November 2010 23:41, Alexander Graf <agraf@suse.de> wrote: >>> >>> On 23.11.2010, at 22:25, adq wrote: >>> >>>> This patch ups the APIC version from 0x11 to 0x14. After that Mac OS X >>>> loads successfully (with appropriate kexts, applesmc ain't hooked up >>>> properly yet I see unfortunately). >>> ) >>> AppleSMC emulation is upstream, but the ACPI entries are missing. Once you add those, all is fine. >> >> Ah yeah, I've just this minute added the DSDT entry from your patch >> for the SMC device and it now works with the vanilla SMC driver. Nice >> work! >> >> It *is* annoying that IASL now erroneously(?) complains about the >> hypen in "Name (_CID, "smc-napa")" though. >> >> Adding the HPET DSDT data causes it to claim it can't support the >> hardware (and a zillion more DSDT errors); I'll have a play about with >> that (perhaps its just the new DSDT validation stuff).. > > Interesting. I was also thinking that maybe we can leverage overriding mechanisms that are already available. Maybe it's possible to squeeze the HPET node into an SSDT. Maybe we need to override the whole DSDT from the command line. The HPET issue was actually because the seabios already contained an HPET definition and mac os X didn't know quite what to do with a CPU with two APICs :) I removed the spare HPET def, and it doesn't moan about unsupported hardware anymore. However AppleIntelCPUPowerManagement dies with a bad opcode error and no useful information on why.. I get the impression that worked OK unmodified with your original suite of patches? Obviously if you disable the KEXT its no longer a problem, but it would be nice not to have to. 10.6.5 still doesn't start the GUI though, and I've still no idea why yet. Also, mac os x reports that an emulated e1000 device has an all-zero MAC address. I'm going to look into this first since the rtl8139 only has 32 bit drivers it seems.
On 25 November 2010 11:46, Jan Kiszka <jan.kiszka@siemens.com> wrote: > Am 24.11.2010 12:00, Alexander Graf wrote: >>>>> According to to the Intel IA-32 Software Developers Manual Vol 3 page >>>>> 290, the version should be 0x14 Pentium 4/Xeon CPUs anyway. >>>>> >>>>> Signed-off-by: Andrew de Quincey <adq@lidskialf.net> >>>>> >>>>> diff --git a/hw/apic.c b/hw/apic.c >>>>> index 5f4a87c..20304e0 100644 >>>>> --- a/hw/apic.c >>>>> +++ b/hw/apic.c >>>>> @@ -704,7 +704,7 @@ static uint32_t apic_mem_readl(void *opaque, >>>>> target_phys_addr_t addr) >>>>> val = s->id << 24; >>>>> break; >>>>> case 0x03: /* version */ >>>>> - val = 0x11 | ((APIC_LVT_NB - 1) << 16); /* version 0x11 */ >>>>> + val = 0x14 | ((APIC_LVT_NB - 1) << 16); /* version 0x14 */ >>>> >>>> What exactly changed between the versions? Did new registers get introduced or subtle behavior change? Is there some proper documentation on the changed between the apic versions? >>> >>> I've been trying to find out; I'm still searching intel's docs to find >>> an 0x11 version to compare with :( >> >> Please try very hard. I haven't found anything myself either yet, but without a spec it's hard to justify these changes upstream :(. >> >>> The failure mode is that mac os X SL whines about the APIC being an >>> unexpected version (0x11) and it wants 0x14 as a minimum. >> >> Yup, I remember that issue. To really make this all useful, we also need to change the numbers in KVM though. > > Also, the version has to be set depending on the emulated CPU (even more > when there will be emulation differences). Indeed. However, I've just been comparing the two docs (and yes it IS a huge pain in the bum!). The differences between the pentium/P6 (0x11 "APIC") and pentium4/xeon (0x14 "xAPIC") so far are: * LVT themal sensor 0xfee0330 is new in xAPIC -- this is already implemented in hw/apic.c * APIC ID register is 8 bits in xAPIC, 4 bits in APIC (top 4 are undefined) -- already 8 bit wide in hw/apic.c * APIC LVT count should be 4 in APIC, 6 in xAPIC -- already hardcoded to 6 in hw/apic.c * Spurious interrupt vector should have the lower 4 bits hardcoded to 1 in APIC -- this is not done in hw/apic.c - they're modifable. * Base address of LAPIC can be changed using an MSR in xAPIC, suppposedly not possible in APIC - hw/apic.c allows it no matter what. (I'm still reading) From what I can see hw/apic.c already unconditionally supports all the features of the newer APICs anyway, and any changes are really just incremental tweaks. The other major difference between APIC and xAPIC is how they talk to each other in hardware: APIC has an APIC bus, xAPIC uses the system bus. I suspect this isn't a concern for emulated hardware though...
On 25.11.2010, at 22:03, adq wrote: > On 25 November 2010 11:46, Jan Kiszka <jan.kiszka@siemens.com> wrote: >> Am 24.11.2010 12:00, Alexander Graf wrote: >>>>>> According to to the Intel IA-32 Software Developers Manual Vol 3 page >>>>>> 290, the version should be 0x14 Pentium 4/Xeon CPUs anyway. >>>>>> >>>>>> Signed-off-by: Andrew de Quincey <adq@lidskialf.net> >>>>>> >>>>>> diff --git a/hw/apic.c b/hw/apic.c >>>>>> index 5f4a87c..20304e0 100644 >>>>>> --- a/hw/apic.c >>>>>> +++ b/hw/apic.c >>>>>> @@ -704,7 +704,7 @@ static uint32_t apic_mem_readl(void *opaque, >>>>>> target_phys_addr_t addr) >>>>>> val = s->id << 24; >>>>>> break; >>>>>> case 0x03: /* version */ >>>>>> - val = 0x11 | ((APIC_LVT_NB - 1) << 16); /* version 0x11 */ >>>>>> + val = 0x14 | ((APIC_LVT_NB - 1) << 16); /* version 0x14 */ >>>>> >>>>> What exactly changed between the versions? Did new registers get introduced or subtle behavior change? Is there some proper documentation on the changed between the apic versions? >>>> >>>> I've been trying to find out; I'm still searching intel's docs to find >>>> an 0x11 version to compare with :( >>> >>> Please try very hard. I haven't found anything myself either yet, but without a spec it's hard to justify these changes upstream :(. >>> >>>> The failure mode is that mac os X SL whines about the APIC being an >>>> unexpected version (0x11) and it wants 0x14 as a minimum. >>> >>> Yup, I remember that issue. To really make this all useful, we also need to change the numbers in KVM though. >> >> Also, the version has to be set depending on the emulated CPU (even more >> when there will be emulation differences). > > Indeed. However, I've just been comparing the two docs (and yes it IS > a huge pain in the bum!). > > The differences between the pentium/P6 (0x11 "APIC") and pentium4/xeon > (0x14 "xAPIC") so far are: > * LVT themal sensor 0xfee0330 is new in xAPIC -- this is already > implemented in hw/apic.c > * APIC ID register is 8 bits in xAPIC, 4 bits in APIC (top 4 are > undefined) -- already 8 bit wide in hw/apic.c > * APIC LVT count should be 4 in APIC, 6 in xAPIC -- already hardcoded > to 6 in hw/apic.c > * Spurious interrupt vector should have the lower 4 bits hardcoded to > 1 in APIC -- this is not done in hw/apic.c - they're modifable. > * Base address of LAPIC can be changed using an MSR in xAPIC, > suppposedly not possible in APIC - hw/apic.c allows it no matter what. Very interesting indeed. > > (I'm still reading) > > From what I can see hw/apic.c already unconditionally supports all the > features of the newer APICs anyway, and any changes are really just > incremental tweaks. Yes, if you can prove that the one we're emulating basically already is an xAPIC and the only difference is the incorrect version, then I'd completely Ack the patch. > > The other major difference between APIC and xAPIC is how they talk to > each other in hardware: APIC has an APIC bus, xAPIC uses the system > bus. I suspect this isn't a concern for emulated hardware though... The internal bus structure doesn't matter to the emulation, no :). Alex
On 25.11.2010, at 21:24, adq wrote: > On 24 November 2010 11:00, Alexander Graf <agraf@suse.de> wrote: >> >> On 24.11.2010, at 03:40, adq wrote: >> >>> On 23 November 2010 23:41, Alexander Graf <agraf@suse.de> wrote: >>>> >>>> On 23.11.2010, at 22:25, adq wrote: >>>> >>>>> This patch ups the APIC version from 0x11 to 0x14. After that Mac OS X >>>>> loads successfully (with appropriate kexts, applesmc ain't hooked up >>>>> properly yet I see unfortunately). >>>> ) >>>> AppleSMC emulation is upstream, but the ACPI entries are missing. Once you add those, all is fine. >>> >>> Ah yeah, I've just this minute added the DSDT entry from your patch >>> for the SMC device and it now works with the vanilla SMC driver. Nice >>> work! >>> >>> It *is* annoying that IASL now erroneously(?) complains about the >>> hypen in "Name (_CID, "smc-napa")" though. >>> >>> Adding the HPET DSDT data causes it to claim it can't support the >>> hardware (and a zillion more DSDT errors); I'll have a play about with >>> that (perhaps its just the new DSDT validation stuff).. >> >> Interesting. I was also thinking that maybe we can leverage overriding mechanisms that are already available. Maybe it's possible to squeeze the HPET node into an SSDT. Maybe we need to override the whole DSDT from the command line. > > The HPET issue was actually because the seabios already contained an > HPET definition and mac os X didn't know quite what to do with a CPU > with two APICs :) HPET == APIC? And why would it have two? > > I removed the spare HPET def, and it doesn't moan about unsupported > hardware anymore. > > However AppleIntelCPUPowerManagement dies with a bad opcode error and > no useful information on why.. I get the impression that worked OK > unmodified with your original suite of patches? Obviously if you > disable the KEXT its no longer a problem, but it would be nice not to > have to. Are you using KVM? To have that kext do something reasonable, we need major tweaks in KVM. For simple use cases, ignoring some MSRs should be enough. Qemu ignores unknown MSRs by default. > 10.6.5 still doesn't start the GUI though, and I've still no idea why yet. Could be anything really :(. I assume you're already starting with -v? Mac OS X also stores crash dumps somewhere, so you could reboot into single user mode (-s) and check if you can make sense of anything there. > Also, mac os x reports that an emulated e1000 device has an all-zero > MAC address. I'm going to look into this first since the rtl8139 only > has 32 bit drivers it seems. Yeah, the e1000 didn't work for me either. The rtl8139 back then didn't work 100% because of its broken timer implementation, but there should have been some fixes for that in the meantime. At least for the rtl8139 the driver was published open source on the apple developer web page. Not sure if that's still the case with 10.6. Alex
diff --git a/hw/apic.c b/hw/apic.c index 5f4a87c..20304e0 100644 --- a/hw/apic.c +++ b/hw/apic.c @@ -704,7 +704,7 @@ static uint32_t apic_mem_readl(void *opaque, target_phys_addr_t addr) val = s->id << 24; break; case 0x03: /* version */ - val = 0x11 | ((APIC_LVT_NB - 1) << 16); /* version 0x11 */ + val = 0x14 | ((APIC_LVT_NB - 1) << 16); /* version 0x14 */ break; case 0x08:
This patch ups the APIC version from 0x11 to 0x14. After that Mac OS X loads successfully (with appropriate kexts, applesmc ain't hooked up properly yet I see unfortunately). According to to the Intel IA-32 Software Developers Manual Vol 3 page 290, the version should be 0x14 Pentium 4/Xeon CPUs anyway. Signed-off-by: Andrew de Quincey <adq@lidskialf.net> val = s->tpr;