Old West Mac OS
The road behind
Mac OS X 10.0 was released five years ago today, on March 24th, 2001. To me, it felt like the end of a long road rather than a beginning. At that point, I'd already written over 100,000 words about Apple's new OS for Ars Technica, starting with the second developer release and culminating in the public beta several months before 10.0. But the road that led to Mac OS X extends much farther into past—years, in fact.
What is SheepShaver PPC emulator (for Windows + Mac OS X)? SheepShaver is a PowerPC (PPC) emulator which allows you to run Mac OS 7.5 up to Mac OS 9.0.4 on various platforms, such as on Windows. SheepShaver started as a commercial project in 1998 but is now open source since 2002. Mac OS X Leopard (version 10.5) is the sixth major release of macOS, Apple's desktop and server operating system for Macintosh computers. Leopard was released on October 26, 2007 as the successor of Mac OS X 10.4 Tiger, and is available in two editions: a desktop version suitable for personal computers, and a server version, Mac OS X Server.It retailed for $129 for the desktop version and $499.
Mac OS X 10.0 was the end of many things. First and foremost, it was the end of one of the most drawn-out, heart-wrenching death spirals in the history of the technology sector. Historians (and Wall Street) may say that it was the iMac, with its fresh, daring industrial design, that marked the turning point for Apple. But that iMac was merely a stay of execution at best, and a last, desperate gasp at worst. By the turn of the century, Apple needed a new OS, and it needed one badly. No amount of translucent plastic was going to change that.
Apple was so desperate for a solution to its OS problem in the mid- to late 1990s that both Solaris and Windows NT were considered as possible foundations for the next-generation Mac OS. And even these grim options represented the end of a longer succession of abortive attempts at technological rejuvenation: OpenDoc, QuickDraw 3D, QuickDraw GX, Taligent, Pink, Copland, Gershwin, Dylan—truly, a trail of tears. (If you can read that list without flinching, turn in your Apple Extended Keyboard II and your old-school Mac cred.)
In retrospect, it seems almost ridiculously implausible that Apple's prodigal son, thrown out of the company in 1985, would spend the next twelve years toiling away in relative obscurity on technology that would literally save the company upon his return. (Oh, and he also converted an orphaned visual effects technology lab into the most powerful animation studio in the US—in his spare time, one presumes.)
So yes, Mac OS X marked the end of a dark time in Apple's history, but it was also the end of a decade of unprecedented progress and innovation. In my lifetime, I doubt I will ever experience a technological event that is both as transformative and as abrupt as the introduction of the Macintosh. Literally overnight, a generation of computer users went from a black screen with fuzzy green text and an insistently blinking cursor to crisp, black text on a white background, windows, icons, buttons, scrollbars, menus, and this crazy thing called a 'mouse.'
I see a lot more Mac users today than I ever saw in the pre-Mac OS X era, but few of them remember what it was like in the beginning. They've never argued with someone who's insisted that 'only toy computers have a mouse.' They didn't spend years trying to figure out why the world stuck with MS-DOS while they were literally living in the future. They never played the maze. (Dagnabbit!)
AdvertisementToday's Mac users appreciate the refinement, the elegance, the nuances of Mac OS X. Today, the Mac grows on people. It seeps into their consciousness until they either break down and buy one or retreat to familiarity, perhaps to be tempted again later.
The original Mac users had a very different experience. Back then, the Mac wasn't a seductive whisper; it was a bolt of lightning, a wake-up call, a goddamn slap in the face. 'Holy crap! This is it!' Like I said, transformative. For the rest of the computing world, that revelatory moment was paced out over an entire decade. The experience was diluted, and the people were transformed slowly, imperceptibly.
That era ended on March 24th, 2001. Mac OS X 10.0 was the capstone on the Mac-That-Was. It was the end of the ride for the original Mac users. In many ways, it was the end of the Mac. In the subsequent five years (and over 200,000 more words here at Ars), the old world of the Mac has faded into the distance. With it, so have many of the original Mac users. Some have even passedon. Mac OS X 10.0 had a message: the Mac is dead.
Long live the Mac
Mac OS X arose, phoenix-like, from the ashes of the Mac-That-Was. Okay, maybe more like an injured phoenix. Also, Apple didn't light the bird on fire until a few years later. But still, technically, phoenix-like.
A side-by-side test-drive of Mac OS X 10.0 and 10.4 is shocking. The eternal debate is whether this gap exists because 10.4 is so good, or because 10.0 was so, so bad. That said, Apple's ability to plan and execute its OS strategy is not open for debate. In five short years, Apple has essentially created an entirely new platform. Oh, I know, it's really just the foundation of NeXT combined with the wreckage of classic Mac OS, but I think that makes it even more impressive. Two failing, marginalized platforms have combined to become the platform for the alpha geeks in the new century.
Today's Mac users span a much wider range than those of the past. Mac OS X's Unix-like core reached out to the beard-and-suspenders crowd (and the newer source-code-and-a-dream crowd) while the luscious Aqua user interface pulled all the touchy-feely aesthetes from the other direction. In the middle were the refugees from the Mac-That-Was, but they aren't the story here. Mac OS X is about new blood and new ideas—some good, some bad, but all vibrant. The Mac is alive again!
After spending half my life watching smart, talented people ignore the Mac for reasons of circumstance or prejudice, it's incredibly gratifying to live in a post-Mac OS X world. When I encounter a tech-world luminary or up-and-coming geek today, I just assume that he or she uses a Mac. Most of the time, I'm right. Even those with a conflicting affiliation (e.g., Linux enthusiasts) often use Apple laptops, if not the OS.
AdvertisementIn the media, the Mac and Apple have gone from depressing headlines on the business page to gushing feature stories everywhere. Even traditional strongholds of other platforms have fallen under the translucent fist of Mac OS X. Just look at Slashdot, long a haven for Linux topics, now nearly living up to the frequent accusation that it's become 'an Apple news site.' Here at Ars Technica, the story is similar. The 'PC Enthusiast's Resource' from 1999 is now absolutely swimming in Apple-related content.
As much as I like to think that I brought on this transformation here at Ars with my avalanche of words, the truth is that Mac OS X is responsible. Yes, Apple's shiny hardware helped, but it was the software that finally won over those stubborn PC geeks. It helped that the software was shiny too, but it would have all been for nothing if not for one word: respect.
Mac OS X made the alpha geeks respect the Mac. My part, if any, in the transformation of a green-on-black den of PC users into a clean, well-lighted home for Apple news and reviews was merely to explain what Mac OS X is, where it's coming from, and where it appears to be going. The rest followed naturally. It's Unix. It's a Mac. It's pretty, stable, novel, innovative, and different. Mac OS X was powerful geeknip; it still is.
During the first few years of Mac OS X's life, I began my reviews with a section titled, 'What is Mac OS X?' That seems quaint in retrospect, but it really was necessary back then. (The pronunciation tips contained in those sections might still be useful. Even Steve Jobs still says 'ecks' instead of 'ten' sometimes. He also said 'PowerBook' during the last press event. I'm just saying...'MacBook'? Come on.)
Today, Mac OS X has achieved escape velocity. After five years and five competently executed major releases, Apple has earned the right to take a little more time with Mac OS X 10.5 Leopard. Users need a break from the upgrade cycle too. (Well, the software upgrade cycle, anyway.) For all my complaints about the Finder, file system metadata, user interface responsiveness, you name it, I've always been rooting for Mac OS X. I've always wanted to believe. After five years, that faith is finally paying off.
Complacency's not my style, though. I still think Mac OS X can be better, and I continue to hold Apple to a very high standard. I've even got a head start on worrying about Apple's next OS crisis. (See parts one, two, three, and four.) Maybe I've been scarred by Apple's late-1990s dance with death...or maybe I've just learned an important lesson. Maybe Apple has too. I sure hope so, because I don't know if I can go through all that again.
Mac OS X is five years old today. It's got a decade to go before it matches the age of its predecessor, and perhaps longer before it can entirely escape the shadow of the original Mac. But I'm glad I'm along for the ride.
Running Mac OS X as a QEMU/KVM Guest
Gabriel L. Somlo
Last updated: Mon. Sep. 05, 2016Feedback 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.
- 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 :)
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
- 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.
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().
- Master git repo: git://git.qemu.org/qemu.git
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.kext3.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.
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.*.Old West Massacres
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:Old West Mac Os Download
- Master git repo: git://git.seabios.org/seabios.git
Old West Masonic Lodge 813
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