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

Re: [Xen-devel] Darwin Advice?

> I know this comes up periodically, but I don't think it has been discussed
> since the introduction of Xen 3.0.

There have been recent discussions on the Darwin kernel mailing list, so if 
you decide to go ahead with this, or have darwin-related architectural 
questions, that would be a good place to post too.

> I am part of a group of three graduate 
> students who are planning to port the Darwin OS to run on Xen as a project
> for an operating systems class.

That would be funky.

> Officially, this is just to get Darwin up 
> and running, but getting OS X running under Xen would be a fun bonus.

That'd be really cool :-)

A few points:
1) whether this is "allowed" by Apple will depend on the interpretation of the 
license agreement - worth checking out
2) You'd have to deal with Apple's protection measures to ensure their OS only 
runs on their hardware.  On PPC OS X it was possible to run with a kernel 
you'd built yourself, on x86 I'm not sure if this is doable (for a while the 
open source Darwin/x86 had been left behind by changes in the MacOS X one, 
and they weren't driver compatible)

> First, we are wondering if porting Darwin is even necessary or
> "interesting" anymore, now that Intel has hardware virtualization support.

Well, I'm not sure to what extent it would be "new" in terms of *research*, 
although nobody has a complete microkernel based OS running on Xen (although 
Darwin's XNU is not really a microkernel AFAIK).  I'm not sure how big the 
userbase would be, but new ports are good fun - particularly if it brought OS 
X closer to running on Xen... :-)

> Second, we are looking for technical advice and/or resources from anyone
> who has experience porting kernels to Xen, or who knows about
> Darwin/Mach/BSD issues.

You may be able to leverage code from the NetBSD port of Xen, although I 
believe Darwin uses a different driver API, which you might need to port to.

There is BSD-alike licensed driver and startup code in the Xen tree (see the 
Minios and the Linux frontend drivers) that you could leverage as a starting 

A possible "way in" might be to work at getting paravirtualised drivers 
working to accelerate IO in a fully virtualised machine (you'd need to test 
if Darwin actually runs in Xen's HVM mode first and fix any problems with 
reference to this list!).  You'd have to write some extra stuff (e.g. the 
driver for the Xen fake PCI device) in order to make this work, but it would 
be useful for people wanting to accelerate fully virtualised Darwin, and 
might get you a bit closer to having the paravirtualised drivers working 
properly...  (I'm not sure how similar to the fully paravirtualised case the 
PV-on-HVM driver code is but I think it should be a step in the right 

> Finally, if we don't end up going the Darwin route, 
> we are open to suggestions for other Xen-related projects that are
> interesting and technically challenging.

There was a roadmap document posted to the list last year that still contains 
plenty of work-in-progress stuff, as well as things that have yet to be 
implemented.  You might find something in there.  I don't have a link but 
it'll be in the archives - it was posted by Ian Pratt last summer/autumn 

One thing off the top of my head (probably fairly difficult): adapting Xen to 
allow owners of domains to carve up their memory and CPU allocation and start 
domains of their own.  This could allow users of virtual machines to start 
their own domains without allowing them to circumvent resource restrictions.

Lots of other stuff in that document though, and you may find help and 
suggestions on this mailing list.


Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.