Simon's Lament Mac OS

• Simon's Lament Mac Os Catalina
• Simon's Lament Mac Os X
• Simon's Lament Mac Os Download

Last major update, 2005/04/03

1. This work started out as my OS Practicum project during the Fall of 2012, where I picked Mac OS X on QEMU/KVM as my topic. I'm a 'native' Linux user, but my IT department supports quite a few Mac OS X users, and I decided I could be much faster and more productive if I could access a Mac as a VM guest rather than dual-boot or cold-start an.
2. My Mac Software. I've written a lot of Mac software over the past ten years. Here are some personal projects that are mostly still current. You can find more about my professional projects on my work page. MT-NewsWatcher—a Usenet client for Mac; MacCVS Pro—a GUI-based CVS client for Mac; Chronoscope—a profiling tool for Mac OS 9.

Mac.appstorm.net You throw away a folder without checking its contents, or prematurely decide you won't need a certain file anymore. That's why you should consider using an application like Disk Drill; to protect you against yourself and the fancies of technology. What's the OS environment? I picked Mac OS X because my main computer is a Powerbook. I have a wireless connection which allows me to work wherever I wish. The OS X is 10.3.8. Editing the code I do most of my editing XCode, Apple's free IDE for Mac OS X. This is the IDE I am most familiar with.

NB: I have not yet switched to Tiger because I'm in the middle of a development cycle.If you get it to work on Tiger, please let me know about it.I'll update this document once I upgrade.

Preamble

So you want to program for the millions of symbian cell phones using C++, but you justcan't stand Windows. Or you don't want to shell out the $$$ for codewarrior. Or you feelmore comfortable programming in a standard UNIX environment. Or you prefer using normal makefiles to the utterly hideous makmake build system.Or you just want to stick it to 'the man' and try something different. Here I've tried to document the procedure I used to setup, install and program for Symbianon a Windows-free environment. Mac OS X is required.

Looking for Linux?

This used to be a Linux / OS X hybrid howto, but the whole point for me all along wasto be working on OS X. now it's finally possible to do that, so I've rewritten itto be OS X focused.However, the simple fact that you can do this on OS X means that you can do it on Linuxas well, in fact more easily at this point.Many of the tips in this howto apply equally well to Linux.If you want to do Symbian dev on Linux, I recommendyou use Rudolph König's sdk2unixwhich has become fairly straightforward I think.(I use it, in modified form, below.)There's also a complete resource list at the end of this HOWTO.

Changes

2005/04/02

Complete revision of the HOWTO to be specifically for building right on OS X.Which is what I always intended anyway, but it wasn't possible until this year.

2004/12/26

There have been some developments since the last major update that aren't includedin this HOWTO yet.

• Rudolf Koenig has moved his sdk2unix files to his home page. The lastest version is newer than the one used in this HOWTO:version 1.4.For Series 60, it still uses the old GCC (gcc.539.src.zip) and the Series 60 SDK 1.2.
• The Symbian GCC Improvement Projecthas released a Symbian GCC compiler based on GCC 3.0.Reports indicate that the compiled code is substantially faster on the device,faster than what you get from Symbian Corp's own version that is.Speed and size improvements are in the range of 10%.It should be possible to substitute in something like gcc-3.0-psion-98r2 in forthe official version when you reach that step in Rudolf's instructions.

Read this

A few notes before we begin.

Nokia-oriented but not Nokia-specific

Simon's Lament Mac Os Catalina

This HOWTO will guide you through installing the Nokia Series 60 SDK. It just happenscoincidentally that Series 60 is by far the most popular of all the Symbian flavours.However. if you want to program for say UIQ or whatever you can still use most of theseinstructions, because the whole toolchain (including sdk2unix) is designed to work with anyof the SDKs.

There is no emulator

There's no emulator available. I suppose it's no shock that the nokia emulatorfor windows doesn't run on Mac OS X. In fact, it doesn't run onwine either.Is that really such a bad thing? It depends. The 'emulator' is actually NOT an emulator,it's a simulator. It doesn't actually emulate the ARM instruction set. Instead, theyhave effectively ported the entire Symbian / Series 60 API to windows. You build a windowsbinary file, which links against the ported libraries. So you can't actually take yourARM binaries and try them out in the emulator. There are some fairly major differencesbetween the simulator and the real Symbian /Series 60 devices. One would be speed, butthe most major is in memory management. There are however other more subtle differences.

It's fairly easy to set up logging to a file on the target device. So as long as youhave had some practice debugging code with the use of extensive printf-style statements,it's possible to get along quite well (in my opinion) without the simulator or the debugger.

What's the OS environment?

I picked Mac OS X because my main computer is a Powerbook. I have a wireless connectionwhich allows me to work wherever I wish. The OS X is 10.3.8.

Editing the code

I do most of my editingXCode, Apple's free IDE for Mac OS X. This is theIDE I am most familiar with. I'm sure that something like Eclipse would also be justfine, but this is what I use. I also do a fair bit of editing with command-line emacs.

Deploying builds

Here's another reason to use Mac OS X. OS X comes with very high-quality supportfor bluetooth that includes all of the various Series 60 phones. So, deploying is a simple matter of drag-and-drop onto the bluetooth icon. You transfer the app to thephone, it shows up as a message, the installer will launch automatically. Mostsymbian binaries are pretty small, so transfer times are minimal.

Another strategy is to copy the binary up to a web server that's publicly accessible.Then you can bookmark the location on your phone and download it 'over the air' (called OTA).Again, the installer will kick in and install automatically. This will drive up yourdata bill though.

Now that we have those items out of the way, now we get to the installation.

Prep your local system

You should install the full suite of Apple's free developer tools.

You should also installfink in order to get various command-linetools that you'll need along the way.If you get to some step below that requires a command-line tool (e.g. bunzip2, recode) that youdon't have, you need to install it from fink.(Some fink tools may only be available in the unstable tree, see thefink documentationfor details on how to access it.)

You may also need X11, e.g. Apple's free X11.Without X11 you might have problems with missing libraries when you build gccor something else.

Install gcc

Let's get started.

We're going to use the slightly old version of gcc that Symbian still amazinglyuses. It's called 'gcc539'. We're going to usea version that's been modified by Alfred E. Heggestad.

This will create a directory 'src' with the gcc code in it.Now get a patch by Andre Howe.(You're going to have to patch code quite a few times in this HOWTO.Hopefully the package maintainers will integrate these fixesinto their code sooner or later and this won't be necessary any more.)

You now have a patched src directory. Next you have to pick a destination directory. This is where gcc will be installed. I recommend/usr/local/symbian (you'll need root access).Create the destination dir and then build gcc.

Well, despite all the patches, you're still going to get an error from src/libiberty/strerror.c. So hand apply the following change (basically just comment out lines 465 and 466).

Online casino vip program. .and make again. It's going to take a little while.Finally, install it (requires sudo for root access).But first, fix a stupid permissions problem that also needs to be fixed.

Now symbian gcc is installed.

Install makesis, rcomp, bmconv, petran

These are all essential tools to build symbian apps. The story is, thatSymbian kindly open sourced a number of tools in order to make it easier for peoplelike us to play. The packaged SDKs however only come with compiled EXEs for windows.So we just have to get the source and build them ourselves.

This is pretty straightforward. Get the source, unpack, make, test, install.

makesis

rcomp

At this point you might hit a snag, a lot of test failures. I applied this patch, from here, but it still failed all kinds of tests. Oh well. It seems to work anyway.

bmconv

petran

Install sdk2unix

sdk2unixis a tool by Rudolf König. It replaces the idiotic makmake systemthat Symbian uses with a sensible and normal makefile system. And, it does a wholelot of conversion on the SDK to make it work sensibly in a Unixy kind of way.It's really good stuff.

Rudi provides his own installation instructions which are fine for Linux butyou can't use them for OS X (at the moment, anyway) so ignore them. Everythingwill be explained here.Note that sdk2unix supports other SDKs too, like UIQ, etc, not just Series 60. Time (itch) mac os.

Anyway, download and unpack it.

Now copy some of its useful stuff to where we installed the compiler.

Create some links.

genaif

genaif (a special sdk2unix tool) requires a patch to make it work on OS X.You need to get the genaif patch from . mailing list archives (we're on the bleeding edge here people) . and copy and pasteit into a file called 'patch.txt'.When you build genaif, ignore the warnings about PutLong etc.

Install the Software Developer's Kit

The SDK contains the essential tools and libraries to developfor whatever phone you target. All of the important Symbian SDKs can be found atSymbian's site.

DownloadSeries 60 SDK 2.1 for Symbian OS, Nokia Edition(you have to use the web interface.).It should come out as S60_SDK_2_1_NET.zip, 115.9 MB.Don't unzip it.

Decide where you want to store the final SDK. I personally use~/sandbox/symbian/SDK_21 . this could be useful later on if you want to have multipleSDKs installed. As aventuras de ovoide mac os.

Meanwhile, I'll assume that you've downloaded the zip file to ~/Desktop. Don'tunzip it. That will be done for you automatically by code that I wrote that Rudiput into sdk2unix.Now invoke sdk2unix's magic install command, with the location of the SDK archive, where you want it to go, and the location of the symbian gcc you installed before.

And that's it. You're done installing the SDK. Let's build something.

Build a S60 example

sdk2unix installs makefiles into several of the series60ex directories. You canfind them using the Finder or the find command.

I assume you are familiar with makefiles. If not you might as well start with the GNU Make page.

Fix core makefiles

There's a set of core makefiles that we copied into /usr/local/symbian/lib/makerules.You'll need to hand-apply the following patch to epoc.general to make it work,since we deviated a little bit from the default sdk2unix install.Obviously SDKLOC should be where you put the SDK on your system.

(Note: this is actually a little bit messed up if you want to actually separate the SDK and the gcc installation properly. But I haven't quite figured outhow to do that yet.)

Recode the example files

For some reason sdk2unix didn't recode the examples. You need to recodethem from DOS to UNIX formats. Mainly this affects the line endings. If you don't do this,you're going to get loads of errors from rcomp.

Fix example makefile

Now we're going to build an example, specifically the series 60 form example.It's in series60ex/form.In the src directory,there's a makefile, installed by sdk2unix, but it needs to be fixed a bit.(These are flaws from sdk2unix.) Aristocrat helix manual.

NB - You must also change the first line to reflect your own path to the symbianlibraries e.g. /usr/local/symbian.

Build

When you've applied those changes, now make sure you are in the src directory, and type make.

Include files and case sensitivity

You might get some errors about missing include files.

Many of the source files in the examples have #include statements that usethe wrong case for include files. They will include upper case letters but sdk2unixconverted everything to lower case. The DOS/Windows filessystem is case insensitive butevery UNIX including Linux and OS X is case sensitive.

Edit the source files and lowercase the names of the includes.When you're done and everything works you should get this result from make.

Install on the phone with bluetooth

Assuming you've already paired the phone, fire up the Bluetooth File Exchangeapp and copy aknexform.sis to the phone. Install and run it. It will show off a bunchof different kinds of forms that S60 supports.

Adapting the makefile to your own app

You can basically copy the form makefile to your own app. It should be fairlyself-explanatory how to change it. One gotcha is that there's a rule in it:

You have to change that to:

General tips

On-target logging

There is no on-target debugger so you'll have to use some file of file loggingto find out what your program is doing. Get yourself a copy of the free and excellentFExplorerfile utility for symbian. https://game-namesbonus-online-shootout-ctpkw-penalty.peatix.com.

To log to a file, you can use the RFileLogger API. Something like this:

NewLC's Creating log fileshas more details.

Display extended error codes on the phone

You'll definitely need to read this article as well:Display the extended panic code in Emulator or Device.

Helpful resources

Discussion groups

NewLChas excellent articles andforums.

Forum Nokia discussion areais another excellent resource you can search with their advanced search function (it's not indexed in google.). Jumphobia xl mac os.

publicnews.symbiandevnet.comcan be helpful for highly technical questions not specifically oriented towards Series 60.

SymbianOS.org

Open Source programs for SymbianOShas code, mailing lists, online forums, a wiki, etc. for open source developmentfor and on Symbian.

Symbian GCC Improvement Project

You might also want to experiment with gcc's from the Symbian GCC Improvement Projectwhich are newer but I can't guarantee they'll work.

gnupoc

There is more of a straight port of Symbian tools for Linux called GnuPoc. (It's a play on the hideous name EPOC which was what Symbian was called back in the 90s.)The gnupoc projecthas generated some great ports of various symbian tools to Linux and OS X.However, as a complete system, I tried out gnupocand found it unsatisfying. Just like on windows, it uses makmake and that's just a mess. However, they claimto have an emulator for some of the UIQ phones so if you're developingfor those phones you might want to check it out.

Help and feedback

Simon's Lament Mac Os X

Hopefully everything will work! If it doesn't, feel free to email me. I'll try to help.

Running Mac OS X as a QEMU/KVM Guest

Gabriel L. Somlo

Last updated: Mon. Sep. 05, 2016
Feedback to: somlo at cmu dot edu

0. I Just Want It Working, Right Now !

OK, here's what you'll need (or skip to the technical details instead):

• Development Tools: git, gcc[-c++], [auto]make, iasl, kernel-devel, etc. On Fedora,should take care of it. But, if following the rest of the directions below, you get weird build failures and other unexplained errors, consider the possibility that you're missing something in this category, possibly something I didn't think of listing explicitly above.
• KVM: As of kernel version 3.15, all necessary functionality is already integrated upstream. Right now, I have 3.15.3-200.fc20.x86_64 on my Fedora 20 machine, and everything works out of the box.For older kernels, it may be possible to build KVM kernel modules using the kvm-kmod 'wrapper', by following these instructions.Then, as root, while still in the kvm-kmod directory (substitute kvm_amd for kvm_intel, depending on your CPU):
• QEMU: Download QEMU 2.1.0 or later. This contains and installs an appropriately patched SeaBIOS binary as well, so there's no longer a need to download, build, and install a separate instance of SeaBIOS. Configure and build QEMU using something like:
• Chameleon: an additional bootloader is currently needed to bridge the gap between SeaBIOS and the Apple EFI BIOS expected by Mac OS X. Source is available from the project's SVN repo, but since it requires Mac OS X and Xcode to build, I've uploaded a binary image which you may use until you're ready to build your own.

Once the above components are in place, you'll need a HDD image for your Mac OS X guest:As of Yosemite (OS X 10.10), on kernels older than 4.7, we need to tell KVM to ignore unhandled MSR accesses (During boot, Yosemite attempts to read from MSR 0x199, which is related to CPU frequency scaling, and is clearly not applicable to a VM guest):To start your Mac OS X guest in QEMU, use the following command line:Optionally, to start an SMP guest, one could use something like:When running the OS X guest for the first time, you'll need to install the operating system to the HDD image, so you'll need to add (and boot from) an install DVD image on the command line.SnowLeopard (10.6) was the last OS X version released in DVD format. Starting with Lion (10.7), an install DVD (.iso) image may be generated on an OS X machine by following the steps below (Thanks Dick Marinus for pointing out the Yosemite-specific updates!):There are still a few remaining issues to be worked out:

• You will need to supply the correct 64-character string as the argument of the osk='.' command line parameter above. This string is the concatenated result of two 32-bit keys, OSK0 and OSK1, which can be read from the AppleSMC chip shipping on genuine Apple machines. I wrote a small userspace program based on the Linux kernel applesmc driver, SmcDumpKey.c, which can be used (on a Mac running Linux) to query the SMC for various key values. For the full details, please see here.
• SnowLeopard (10.6), Lion (10.7), MountainLion (10.8) and Mavericks (10.9) can all be booted, with the following caveats:
  • 10.6 and 10.7 require the 'idlehalt=0' kernel argument to be passed in (e.g., at the Chameleon 'boot:' prompt) to avoid using the unsupported MONITOR and MWAIT CPU instructions.
  • 10.6 and early versions of 10.7 (somewhere prior to 10.7.5) will crash with a 'HPET not found' panic on a PIIX + SMP guest. This can be fixed with this patch, but since the problem only occurs on relatively early versions of OS X on the 'secondary' platform (PIIX, as opposed to the 'primary' Q35), I've decided to hold off on trying to upstream it for now.
  • Early 10.8 (definitely 10.8.0) will hang during boot for unknown reasons. Using 10.8.5 boot media (DVD iso or installed HDD image) works fine.
  • 10.9 'firstboot' (i.e., booting from a freshly installed HDD image for the first time) only works with SMP, for currently unknown reasons. Once the initial setup is complete, the HDD image can be booted on either SMP or uniprocessor guests.
• The main goal of this work is to get Mac OS X working with upstream KVM/QEMU/etc., so I'm mainly targeting these projects' git master branches. The patches I refer to may work against recently released versions, but please consider that as nothing more than a happy coincidence :)

Legal Disclaimer: I am not a lawyer, and this is not legal advice. Taking into account that OS X is now officially supported on commercial virtualization solutions such as VMWare Fusion and Parallels, and after a careful reading of Apple's OS X EULA (which states that '[.] you are granted a [.] license to install, use and run one (1) copy of the Apple Software on a single Apple-Branded computer at any one time'), it is my belief that it's OK to run Mac OS X as a QEMU guest, provided the host hardware is a genuine, Apple-manufactured Mac computer, running an arbitrary (e.g. Linux) host OS. This happens to be how I'm using it, but YMMV.Please read on for a detailed overview of all the issues involved !

1. Intro, Motivation, and Overview

This work started out as my OS Practicum project during the Fall of 2012, where I picked Mac OS X on QEMU/KVM as my topic. I'm a 'native' Linux user, but my IT department supports quite a few Mac OS X users, and I decided I could be much faster and more productive if I could access a Mac as a VM guest rather than dual-boot or cold-start an additional machine each time it was needed.The original work to enable OS X to run under QEMU/KVM was done by Alexander Graf. Additional kernel and userspace patches were contributed by René Rebe. Previously available patches and documentation I reviewed include:

• René's patches at T2
• The by now really out of date Wiki instructions at
  http://d4wiki.goddamm.it/index.php?title=Howto:_Mac_OSX_on_KVM

Several different components must successfully interact with each other to facilitate running Mac OS X as a QEMU/KVM guest. Each component is listed below, with a link to its dedicated section covering relevant aspects and outstanding issues related to Mac OS X guest support:

• KVM Kernel Module: at the lowest level, this component provides an in-kernel hardware assisted virtualization infrastructure.
• QEMU: userspace emulator which takes advantage of the hardware virtualization facilities provided by KVM to run a guest at nearly native hardware performance.
• SeaBIOS: default BIOS used with QEMU.
• Chameleon: a bootloader used to bridge the gap between SeaBIOS and the EFI-compatible BIOS shipping with Apple hardware.

2. KVM Kernel Module

KVM is the component located at the lowest level, providing an interface to the virtualization support offered by (among a few others) the x86_64 hardware architecture. Let's begin with a brief list of upstream resources:

• Master git repo: git://git.kernel.org/pub/scm/virt/kvm/kvm.git
  This is actually a full clone of the mainline kernel git repo, with KVM-specific commits added on top. Therefore, it is slightly less convenient to work with, although any attempts at commiting changes upstream must apply cleanly (and work correctly) against it.
• Kmod 'wrapper': git://git.kiszka.org/kvm-kmod.git
  This allows building KVM kernel modules against (and loadable into) a distro kernel (such as what ships on e.g., F18), as shown here.

Earlier OS X versions (up to 10.7 a.k.a. Lion) indiscriminately use MONITOR and MWAIT instructions, which are not currently supported by KVM and which result in an 'invalid opcode' fault when a guest attempts to execute them. A thorough explanation is given here. Beginning with 10.8 (MountainLion), the OS X kernel follows the recommended practice of checking CPUID for MONITOR/MWAIT support, and will not attempt to use them if not supported. To run 10.7 or earlier versions of OS X, either apply this additional KVM patch, or, on an already installed HDD image, run:to prevent OS X from attempting to use the unsupported instructions.The last KVM patch required to boot OS X (already applied upstream) is a misleadingly simple-looking one liner, which removes a single line from virt/kvm/ioapic.c (or x86/ioapic.c in the kvm-kmod version):Without removing this line, a Mac OS X guest hangs during boot with an error message that reads: 'still waiting for root device'.Modern x86 system design includes Intel's IOAPIC (interrupt controller) chip, which receives interrupts from peripheral devices and forwards them to the appropriate CPU's local interrupt controller (LAPIC). The IOAPIC can be programmed to handle both level and edge triggered interrupts. Historically, with the IOAPIC's predecessor (the 8259 PIC), level triggered interrupts were considered 'active' (or 'asserted') when the line went 'high', and 'inactive' when the line remained 'low', from an electrical standpoint. In other words, the 'logical' state of an interrupt line coincided with its 'physical' state. With the IOAPIC, it is possible to configure each individual input (interrupt line) to use the 'classic' interpretation of 'active' vs. 'inactive', now referred to as 'ActiveHigh', or to reverse it by setting a per-input-line 'polarity bit', so that interrupts are considered asserted when the line drops to 'low' from a default inactive 'high' voltage state. This mode is known as 'ActiveLow'. With 'ActiveLow', the physical state of the line is the exact opposite of its logical state.ACPI-compliant operating systems are expected to query the firmware for an indication of which polarity type (ActiveLow or ActiveHigh) to use for any devices with level-triggered interrupts, and to configure the IOAPIC registers accordingly. Both QEMU and KVM have accumulated a significant number of optimizations based on the assumption that guest operating systems use ActiveHigh polarity, and are coded to assume that 'physical' and 'logical' IRQ line states are in sync. Even when a misbehaving guest OS (you guessed it, OS X does this) ignores the ACPI polarity hint (which in QEMU/KVM is ActiveLow, i.e. 'physical'logical') and configures the virtual IOAPIC with the wrong polarity bit values, both QEMU and KVM will mostly use 'logical' IRQ line levels.The referenced patch removes the last place where KVM attempted to care about the value of the polarity bit placed into the IOAPIC register by the guest OS. Because logical levels were assumed everywhere else, looking at the polarity bit could result in flipping the given 'logical' line state at the wrong time, resulting in level triggered interrupts being ignored instead of handled. Once we stop paying attention to the polarity bit values, things work fine. Logical IRQ levels are passed into KVM from userspace by QEMU, and whatever the guest OS does when it programs its IOAPIC polarity bits doesn't matter. Thus, when OS X wrongfully ignores QEMU's ACPI and proceeds with a hard-coded ActiveLow polarity, things just work in spite of that.

3. QEMU

QEMU is a multi-architecture emulator running in user-space. For certain architectures (such as x86_64), QEMU is able to take advantage of hardware virtualization features offered through e.g. KVM, which allow it to run guests at near-native performance levels. Here is roughly how QEMU and KVM work together to implement a guest VM:

• QEMU starts as a user-mode process, launching one thread for each VCPU that will be part of the guest VM. The guest system's 'physical' memory is allocated as part of the virtual address space of the QEMU process, and various handlers for the emulated virtual hardware of the guest systems are prepared.
• Each QEMU VCPU thread makes an ioctl() call into the kernel (where it will be serviced by KVM), requesting that the VCPU be scheduled on a pyhsical core. This ioctl() call will only return to userspace if/when KVM encounters a VM exit it can't handle itself. This typically involves a need for userspace emulation of specific guest hardware. Normally, when the userspace emulation is complete, the QEMU VCPU thread loops back to the spot where it calls into the kernel via the ioctl().
• KVM handles the kernel-side of the ioctl() call made by each QEMU VCPU thread. Normally, it causes the physical core on which the thread is scheduled to enter VM guest mode (a.k.a. L>1). Whenever a VM exit (back to host mode) occurs, KVM attempts to handle the exit cause itself, and immediately re-enters VM guest mode if successful. Otherwise, the VM exit reason is passed back to userspace by falling out of the ioctl() call, at which point QEMU must handle it as described above, before calling back into KVM again via the ioctl().

A quick list of QEMU upstream resources might include:

• Master git repo: git://git.qemu.org/qemu.git

There are four relevant topics regarding support for Mac OS X guests: QEMU's recent inclusion of support for the Q35/ICH9 based architecture; emulation of Apple's System Management Controller (a.k.a. AppleSMC), including automatically advertising its presence via ACPI; and, finally, a few issues related to QEMU's emulation of the e1000 network controller.

3.1. The Q35/ICH9 architecture

Support for the Q35 architecture was recently (Dec. 2012) merged into QEMU mainline. Q35 replaces the old I440FX (a.k.a. PIIX) with Intel's more modern ICH9 chipset, which also happens to be used on most Intel-based Apple hardware. Among other hardware, ICH9 includes an integrated AHCI disk controller, which had to be added explicitly prior to the Q35 QEMU command line:As Q35 is slated to become the new default 'machine type' in QEMU in the near future, the bulk of the effort (development, debugging, and testing) to get Mac OS X supported under QEMU will be focused on this platform.

3.1.1. Ethernet Link negotiation issues with e1000 on PIIX

Starting with MountainLion (OS X 10.8), the proprietary e1000 network driver built into OSX (AppleIntel8254XEthernet.kext) fails to detect network link unless special care is taken to move the network card to a separate hardware IRQ line from the AHCI/SATA controller. By default with the above command line (i.e. without using ',bus=pci.0,addr=5'), the network card will be placed in PCI slot 4, and will share IRQ11 with a bunch of other devices (e.g. AHCI/SATA, USB, etc). Moving it to PCI slot 5 causes it to use IRQ10 by itself, which is a sufficient workaround for the problem, at least for now.After some reverse engineering, it appears that the AppleIntel8254XEthernet.kext reads the e1000 ICR (Interrupt Cause Register) each time a PCI interrupt is detected. However, until e1000 initialization is complete, including the final configuration of the e1000 IMR (Interrupt Mask Register), any e1000 interrupts, including LSC (link state change) are ignored. The driver 'knows' it hasn't unmasked the interrupt yet, so while it reads the self-clearing ICR on hardware interrupt, it simply ignores the contents, which is then lost due to the register's reset-on-read behavior.Normally, the driver has enough time to finish setting up the mask register before a PCI interrupt is generated by the hardware when link autonegotiation is completed. However, by sharing a hardware IRQ line with the 'noisy' SATA controller, the hardware interrupt handler portion of the e1000 driver (which reads the ICR) is invoked early and often, before the mask setup is completed, leading to the asserted link state change interrupt being discarded before it can be acted upon.Moving the e1000 card to a new hardware IRQ line away from SATA (by forcing it into a custom PCI 'slot') solves the problem by not invoking the e1000 hardware interrupt handler before setup is complete. Another workaround (suggested by Alex Graf) is to delay reporting the LSC interrupt to the guest until the IMR (mask register) was configured. However, as pointed later in that thread, this patch may be problematic for guests wishing to poll the ICR without relying on hardware interrupts (by setting up a mask). Although mostly a theoretical issue at this point, this patch would significantly differ from expected hardware behavior.

3.2. The AppleSMC emulator

The AppleSMC (or System Management Controller) is a chip specific to Intel-based computers manufactured by Apple. Its main purpose is to control (and report on) fan speeds, temperature sensors, screen and keyboard light intensity levels, and miscellaneous other power management features.From the point of view of the operating system driver, interaction with the SMC happens via port-based I/O: The name of a 4-character key is written to a control port, and the key's numeric or ASCII value is then read from (or written to) a data port. Keys typically represent fan speeds, light intensity levels, or temperatures.A pair of already upstreamed patches advertises the presence of the SMC in QEMU's ACPI/DSDT table, conditionally, based on whether or not it was specified on the QEMU command line.There are currently two outstanding issues with QEMU's AppleSMC emulation which could improve Mac OS X guest support, outlined below.

3.2.1. Automatic OSK 'pass-through' on Apple hardware

The AppleSMC is also used to store a 64-byte ASCII string copyrighted by Apple, spread across two 32-byte key values, named OSK0 and OSK1. This string is used by Mac OS X to determine whether it's being booted on genuine Apple hardware. QEMU does not set up AppleSMC emulation by default (since only OS X guests require it at this time). To set it up, the following QEMU command line snippet is required:The user must supply the correct value of the 64-byte OSK string as an argument, and is responsible for honoring Apple's OS X EULA (which states that '[.] you are granted a [.] license to instal, use and run one (1) copy of the Apple Software on a single Apple-Branded computer at any one time').I wrote a small C program, SmcDumpKey.c, which can be used to read various SMC key values (including OSK0 and OSK1) from an Intel Mac running Linux. However, a significant improvement in usability and ease of compliance with the OS X EULA could be accomplished by allowing QEMU's AppleSMC emulator to automatically acquire the OSK strings from the underlying (Apple) host hardware.Currently, the drivers/hwmon/applesmc.c Linux driver populates a Sysfs directory (/sys/devices/platform/applesmc.768/) which offers access to most SMC key values. Unfortunately, that does not include OSK0 and OSK1. I submitted this patch against the applesmc.c Linux driver, but encountered two main objections (also see the various other replies in the referenced thread):

• /sys/devices/platform/applesmc.768/ is (or should be) reserved for hardware-monitoring related keys and values only; This point seems to be contradicted by Documentation/sysfs-rules.txt in the Linux kernel sources, which states that each device should get its own node (directory) in a device tree, and does not recommend spreading any device's entries into separate spots across Sysfs by any sort of 'category'.
• The OSK values are constant, so it makes no sense to query the hardware if we know ahead of time what the returned value will be. My counter argument to that is that it makes perfect sense to query the hardware each time, precisely because Apple claims copyright on the returned string, which can therefore never be legally hardcoded (and distributed) in any open source project such as QEMU.

I'm planning to follow up with the Linux maintainer of applesmc.c again in the near future to reiterate these points, but in the mean time I could really use some advice and feedback from anyone with successful patch submission experience to the Linux kernel :)

3.2.2. OS X fails to write a key value to the emulated SMC

During boot, Mac OS X will log a few non-fatal SMC-related errors:It appears that emulating a few extra SMC keys, as well as allowing the OS X guest to write (as opposed to just read) some of the supported keys might make these errors go away.

3.3. The virtio-net virtual network card

A great alternative to using the default e1000 virtual network card (albeit one that requires post-install 'surgery' on the guest) appears to be using virtio-net instead (thanks George Yunaev and Warren Togami for pointing this out!). Start the guest with the following additional command line arguments:and install the 'aftermarket' virtio-net driver by Phil Jordan on the guest side. Since our guest does not have a network connection, download the driver on the host like so:and then start your guest with an additional FAT 'drive' mapped to the './VirtIoNetDrv/' download directory:Once the guest is up, install the driver via the usual method, and restart. A new Ethernet interface should become available, and should work from that point on with minimum fuss. Tested and confirmed working on OS X 10.8.5 and 10.9.*.

3.4. Boot OS X on QEMU without KVM hardware assistance

This now works (albeit very slowly, too slowly to be useful in practice), with the following (already upstreamed) patches:

• OS X requires a software-emulated LAPIC version of 0x14 or higher;
• The software-emulated IOAPIC must ignore polarity bits set by the guest, matching the hardware-accelerated behavior of the KVM IOAPIC.

4. SeaBIOS

SeaBIOS is the default BIOS for QEMU/KVM. The QEMU source tree includes a sufficiently up-to-date snapshot of SeaBIOS (in pre-built, binary form).For reference only at this point, upstream resources include:

• Master git repo: git://git.seabios.org/seabios.git

SeaBIOS has been patched to accept SMBIOS tables generated by QEMU. At this point, all SMBIOS tables will be v2.8 compliant (a version newer than 2.4 is required to support 'About This Mac' without crashing Finder), and the user may specify the inclusion of a Type 2 (Baseboard) entry, required for booting [Mountain]Lion, on the qemu command line:

5. Chameleon

Chameleon is a Darwin/XNU boot loader based on Apple's boot-132. It is currently used to boot OS X on systems which do not contain Apple's EFI BIOS as expected. Project resources include:

• Project home page: http://chameleon.osx86.hu/
• SVN repository: http://forge.voodooprojects.org/svn/chameleon

Chameleon boots the OS X kernel (XNU) in three stages. We are interested mainly in the last stage (known as 'stage 2', counting from 0). The project is designed to be built under OS X itself, and also depends on Xcode. Xcode v5.0.2 (free/beer download via the AppStore) on OS X 10.8 or later can build the latest Chameleon trunk (SVN 2360 at the time of this writing). Once these prerequisites are met, simply running 'make' in the appropriate SVN subdirectory will build the entire project.The Chameleon stage-2 bootloader will be built as '

./sym/i386/boot'. On QEMU, we bypass all earlier stages by loading this binary as the default 'kernel' (via the '-kernel chameleon_svn2783_boot' command line argument). On a (U)EFI compliant machine, in theory, (U)EFI would find a file named '/System/Library/CoreServices/boot.efi' on the OS X partition and use it directly. Chameleon's stage-2 'boot' file is a roughly equivalent replacement for that.Chameleon offers a range of additional 'bells and whistles', such as the ability to load alternative and/or additional

Simon's Lament Mac Os Download

.kext modules (OS X kernel drivers), and replace the system's default ACPI DSDT, mostly intended for 'hackintosh' systems. On QEMU, however, the idea is to offer a DSDT and virtualized 'hardware' that's close enough for OS X to run on, without needing that type of 'assistance' from the bootloader.An example Chameleon configuration (create a new file under /Extra/org.chameleon.boot.plist) is shown below. The example configures Chameleon to automatically enter the first encountered OS X partition after a 5-second wait. It also forces the guest video settings to 1280x1024 pixels, 32-bit color depth (which is something that currently can't be done from *within* the guest's display settings, for reasons I'm still investigating). Thanks to Andrei Ostanin, Christian Simon, and Warren Togami!In the long term, it might be possible to use a QEMU-compatible UEFI BIOS instead of SeaBIOS, and have it boot into OS X using the original /System/Library/CoreServices/boot.efi Apple-provided bootloader.

6. Conclusion and Future Work

My ultimate goal is to upstream whatever changes are needed to KVM/QEMU/SeaBIOS/Chameleon/etc., to allow installing and running OS X from unadulterated, standard images. I plan to keep this document updated with the current list of outstanding issues. Eventually, the idea is for this document to 'melt away' as all these issues are addressed, and all patches are accepted into their respective upstream projects.I appreciate any ideas, comments, and feedback. Please email me at somlo at cmu dot edu with any questions, comments, and suggestions.