> > 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
|
Home