Re: [Qemu-devel] [Patch] Small fix for qemu APIC for Mac OS X support

[adq <adq@lidskialf.net>]

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.