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

[Alexander Graf]

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.

> 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.


Alex