qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alexander Graf
Subject: Re: [Qemu-devel] [Patch] Small fix for qemu APIC for Mac OS X support
Date: Fri, 26 Nov 2010 00:31:08 +0100

On 25.11.2010, at 21:24, adq wrote:

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]