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

["Jayesh Salvi" <jayeshsalvi@xxxxxxxxx>]

Thanks very much Mark for such a detailed response. 

My interest is in runnning Xen in user mode (any OS). A very important application of this I find is in desktop OS. The migration of operating system instance provided by Xen can be used very effectively in carrying one's desktop environment from one machine to another on a tiny storage medium (USB flash storage for instance). I had posted some details about such prototype I had put together (xenonkey).

The problem with such solution in currently available schemes is that, the physical hosts used for migration need to be running Xen dom0s. An alternative is to provide a small dom0 kernel on the portable storage device and reboot the new physical hosts with it and then launch the saved domU desktop instance on top of it. (This approach is used in 
http://www.research.ibm.com/WearableComputing/SoulPad/soulpad.html). But rebooting the physical machine or putting restrictions on its kernel, is inconvinient.

Therefore if xen hypervisor could be implemented as module/kext/DLL(?) we could migrate domUs from one platform to another very easily. AFAIU dom0 and backend drivers will have to be achieved by means of more modules. With my limited understanding I am not sure if there is any serious obstacle in implementing such design.

Portability of desktops is very useful feature, but that need to be implemented with very little configuration changes to the regular user (no kernel changes on his existing machine).

I would like to hear what others think about such idea.

Thanks,
Jayesh
------------------------------------------------------------------------
Everything you can imagine is real

On 4/8/06, Mark Williamson <mark.williamson@xxxxxxxxxxxx> wrote:

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