Re: [Xen-devel] Xen as a kernel module

[Steven Hand <Steven.Hand@xxxxxxxxxxxx>]

>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