Re: [Xen-users] Xen for intel mac?

[Mark Williamson <mark.williamson@xxxxxxxxxxxx>]

> > Right now, you can't really have a dom0 that doesn't know about Xen, but
> > there would be (relatively difficult) ways to hack round that if anyone
> > *really* wanted to make it work (such as making Xen loadable as a kext
> > after
> > boot - this would require a fair bit of Evil Hacking but might work!).
>
> Mark, can you give some pointers where I can get more info about this and
> other hacks, that can make possible to have a dom0 that doesn't understand
> Xen.

Well, it'd be a bit gross really ;-)

The obvious (to me - others may disagree) method of getting Xen in there is to 
build it as a loadable kernel module...

Sombrio systems have made a Xen which runs as a Linux kernel module:
http://www.linuxdevices.com/news/NS3509840836.html

For MacOS, you might want to do something like:

* adjust the Xen build system and binary format so that it can be loaded as a 
MacOS X kext
* write initialisation code to replace the machine bringup code currently 
used.  There'd be no need to initialise the platform, but you would instead 
need to do various ugly hacks including:
 - allocate memory from the host kernel for Xen's heap, shadow pagetables, and 
domain memory
 - hijack the systems interrupt vectors so that Xen can control scheduling
* port the backend / dom0 drivers to run in the "host" MacOS X kernel as 
kexts.  This might involve a different means of communicating with Xen itself 
(function calls not hypercalls...), dealing with the lack of an M2P table, 
etc. [alternatively, you could link the backend drivers with xen.kext as a 
big blob, allowing them to use Xen functions, M2P tables, etc fairly 
directly]
* Port the management tools and make sure they understand any differences 
introduced with xen.kext

The model would be:
* System boots MacOS X
* xen.kext is loaded
 - Xen allocates its own memory and takes control of interrupts so that it can 
control scheduling, avoid itself being pre-empted
* backend driver kexts are loaded
* control tools are run
* control tools bring up normal domUs on top of xen.kext.  The host kernel 
doesn't really know what's going on, other than the fact that xen.kext has a 
lot of memory allocated, and the backend drivers keep generating requests.

Note that this implies a substantial amount of complex hacking...  There are 
lots of subtle cases to consider.  In particular, entering / returning from 
the host kernel is likely to be particularly hairy.  You may want to look at 
how CoLinux (http://www.colinux.org) does it, as it uses a similar technique 
to run Linux co-operatively with Windows.  You may even want to enquire as to 
whether they're considering a port to MacOSX86, which could help 
considerably.

Comment from other people who have thought about the technical implications is 
very welcome!  This is not something I've ever done myself ;-)

Cheers,
Mark


-- 
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-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users