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

[adq]

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