As You Were

Devin Coughlin's blog.
Styles: Serious Spare

March 23, 2004

Virtual Linux

I've been thinking a lot about processor virtualization lately. It has been almost a year since I did any serious work in the area, but I've been thinking recently about quick and dirty tricks to get a virtual machine running.

I've heard rumors that Apple is working on providing some degree of linux compatibility for OS X 10.4, but it is not clear exactly what this means. Presumably, this would be source level compatibility whereby enough linux API's would be added so that most linux software recompiles effortlessly on OS X. I think getting an 80% solution here wouldn't be that difficult because of OS X's BSD roots and the availability of POSIX, but the last 20% would probably be pretty hard, as linux likes to do a lot of stuff (especially device dependent stuff) its own way.

It occurred to me the other night that if I were responsible for bringing linux compatibility to the Mac, I would use a virtual machine instead. Apple already runs a partial virtual machine to support its Classic environment (whereby a virtual mac starts up OS 9 to provide backwards compatibility) albeit without full MMU support and some weird juju to transfer control to and from the main OS.

If you're running on a modern ISA (i.e. NOT x86) virtualizing the processor is actually not that difficult (although getting good performance out of an emulated MMU can be tricky). The hard part is providing fake hardware so that guest OS's can run on the virtual machine. It is usually better to write your own special drivers for the host OS and then pass the hard work off to the real hardware or host OS -- but even this is not an easy task, especially for things like graphics cards and USB devices.

Linux's unix heritage and versatility are greatly advantageous in this area. A completely usable virtual machine (kernel + user-level processes) would really only need one device: an ethernet card.

The boot-loader firmware could load the kernel from a local tftp server. The kernel could load all filesystem data from a local nfs mount. The user could control the virtual machine either through a an ssh terminal or an local X windows server.

The biggest problem with virtual machine monitors is that the lag in the GUI is unacceptable. This is because things that have to handled on time in interrupts (mouse movement, screen refreshing) aren't guaranteed to be run when they need to on the virtual machine. Most linux graphical applications, however, are written for X Windows, so they are designed to not choke (too horribly) over high latency connections.

There are certainly some applications (industrial control, gaming) where this would not work -- but why would you run these on a mac, anyway?

So is there any chance RedBox could be joining BlueBox in the future? Doubtful. But one can always hope.

Posted by coughlin at 12:03 AM | TrackBack (0)