hello, Just reading the OS compatibility page on the xensource wiki; Under Xen 3.0 / Unmodified OS it says ''Initial support for unmodified guests when using Intel VTX hardware, e.g. Windows''. Even though I am not (yet) a Xen user, I''m curious about whether there are any specific plans to get Xen running on intel macs (Mactel-Linux apparently boots but no graphics). Graphics support would be part of what I mean by ''get Xen running'' in the context of an intel mac since I imagine that ''support for unmodified guests'' means osx could boot (as a guest ... alongside ''e.g. Windows'', linux, etc). Having said that, I have no idea how (or even if) Xen manages competing demands for graphics hardware by unmodified guest os''. Would ATI drivers for linux be enough? I hope these questions are not too hypothetical ... apologies if they are. Thanks, Simon _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
At 08:12 PM 4/7/2006, you wrote:>Just reading the OS compatibility page on the xensource wiki; Under >Xen 3.0 / Unmodified OS it says ''Initial support for unmodified >guests when using Intel VTX hardware, e.g. Windows''.There could be issues with TPM and the like, stuff that locks down Darwin to Apple machines. You also need some way to turn on VT technology in those Core Duo processors, or maybe it''s already enabled through EFI?>Graphics support would be part of what I mean by ''get Xen running'' >in the context of an intel mac since I imagine that ''support for >unmodified guests'' means osx could boot (as a guest ... alongside >''e.g. Windows'', linux, etc). > >Having said that, I have no idea how (or even if) Xen manages >competing demands for graphics hardware by unmodified guest os''. >Would ATI drivers for linux be enough?You would be definitely be limited to remote desktop, same as Windows is mostly limited to RDP. I doubt OS X will ever be able to run as a Dom0 since you would have to be able to build a supported custom kernel. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> There could be issues with TPM and the like, stuff that locks down > Darwin to Apple machines. You also need some way to turn on VT > technology in those Core Duo processors, or maybe it''s already > enabled through EFI?You can probably boot Xen somehow... either using mbootpack and Apple''s Boot Camp, or by booting Linux and kexec-ing into Xen.> >Graphics support would be part of what I mean by ''get Xen running'' > >in the context of an intel mac since I imagine that ''support for > >unmodified guests'' means osx could boot (as a guest ... alongside > >''e.g. Windows'', linux, etc).Well what would be *nice* is if it were possible to port MacOSX to Xen and let it boot on top of Xen. Then you could have it control the real display (pretty aqua graphics!) and run other domains with virtual machines. However, there are problems with this...> >Having said that, I have no idea how (or even if) Xen manages > >competing demands for graphics hardware by unmodified guest os''. > >Would ATI drivers for linux be enough? > > You would be definitely be limited to remote desktop, same as Windows > is mostly limited to RDP. I doubt OS X will ever be able to run as a > Dom0 since you would have to be able to build a supported custom kernel.And that''s the problem. Unless Apple make it possible to compile custom kernels for OSX86, it''s certainly not going to be possible to port it to run on Xen (and even then I''m not sure what the implications for their DRM are). 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!). 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@lists.xensource.com http://lists.xensource.com/xen-users
> > > 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. Thanks. -- Jayesh ------------------------------------------------------------------------ Everything you can imagine is real _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> > 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@lists.xensource.com http://lists.xensource.com/xen-users
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@cl.cam.ac.uk> 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@lists.xensource.com http://lists.xensource.com/xen-users