On 24 November 2010 11:00, Alexander Graf <ag...@suse.de> wrote: > > On 24.11.2010, at 03:40, adq wrote: > >> On 23 November 2010 23:41, Alexander Graf <ag...@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 <a...@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.