[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen as a kernel module
>with Xen increasingly depending on Linux for bootstrap, drivers, packet >filtering etc., would it make sense to have the option of compiling Xen >as a Linux kernel module, like in VMWare or coLinux? Huh? Which kind of vmware? Afaik the hosted (type II) versions of vmware when running on a linux host have some modules which get installed but the VMM itself is not a module. And coLinux is basically a windows device driver which does task switching - a very clever and useful piece of software but not really a Linux kernel module. Perhaps you mean: would it make sense to have a type II version of Xen? I certainly see no particular reason to do this, but no particular reason not to either. I'm not sure how much code similarity there would be though... >It seems this would give similar performance to Xen 1.2, while retaining >most of the benefits of the NGIO model (i.e. not having to port >drivers). Maybe - I guess it depends on what you mean. If you have: [ VM1 ] [ VM2 ] .... [ VMN ] [ new type II version of Xen ] [ linux kernel ] [ hardware ] then you require a way for VMx to communicate the new Xen thing, which then needs to syscall into the linux kernel. I'm not sure what VMx<->Xen comms would look like, or how it would perform. If you retain safety it seems like you might end up with the performance of UML, which if you go for 'high performance' then you may need to turn off the safety catch. How did you see this working? What aspects of performance under Xen are you finding unacceptable? There will always be an overhead involved in running N operating systems and apps on a machine compared with just 1. Indeed, if you really want 'blistering performance' you may find that even the overhead of a general purpose OS is too much. Application-specific OSes can increase performance (as can dynamic application-specific code path optimization, see e.g. synthesis, wiggin-redstone, etc). >The only downside would be the lack of driver isolation, but >most people would be willing to live with that is my guess (plus as long >as there is no IO-MMU a bad driver is still able to take down the >complete system anyhow). Well isolation (both security and performance) are two explicit design goals of Xen. If you want to have the illusion of multiple kernels without these properties, you can use linux vservers or BSD jail. We're quite keen to evolve Xen in a way which makes it easier to run multiple configurations, but mainly in the space that /increases/ isolation (e.g. driver domains) rather than the other way. >I imagine this could be done in a way that would also work under other >host-OSes, like *BSD or Windows. Again, I'm not sure how much code-base similarity there would be with either current Xen or the type-II variant that you propose above. One nice thing about a type-I (unhosted) hypervisor is that you are - in principle at least - independent of the OSes you host. This means one can have a dom0 running Linux, BSD, Plan9 or even Windows. With type-II hypervisors you effectively need a new hypervisor for every hosted OS type (e.g. VMware workstation). >Any comments? It might be useful if you were to state what precisely the problem is that you wish to solve, why existing solutions are insufficient, and how your proposed solution would solve the problem. I'm not sure I really understand the answers to any of these at the moment. cheers, S. ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |