WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Steven Hand <Steven.Hand@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Xen as a kernel module
From: Jacob Gorm Hansen <jacobg@xxxxxxx>
Date: Wed, 26 Jan 2005 15:19:26 -0800
Cc: Xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 27 Jan 2005 13:22:36 +0000
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
In-reply-to: <E1Ctijw-0004J6-00@xxxxxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
References: <E1Ctijw-0004J6-00@xxxxxxxxxxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0 (X11/20050116)
Steven Hand wrote:

Maybe - I guess it depends on what you mean. If you have: [ VM1 ] [ VM2 ] .... [ VMN ] [ new type II version of Xen ] [ linux kernel ]
              [ hardware ]

Sorry if this came out sounding as a bit of a troll, anyway, my suggested setup would look like this:

      [ VM1 ]   [ VM2 ] ....   [ VMN ]

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

Right now Xen is mapped somewhere in top of memory, I am not sure how domains are kept out of there, but I suppose it has to do with segments. The good thing about that is that hypercalls are cheap, and in Xen1.x I/O was cheap as well.

My suggestion/question was a) why don't we just put a full Linux up there, including drivers, and b) can we provide the Xen hypercall interface on top of other OSes as well?

How did you see this working?

For Linux, I would relocate it to the top X megs of memory, and I would merge the Xen and Linux syscall handlers, essentially supporting two process models under the same OS. I would not map all of memory to Linux, just the pages it needs for its own stuff. For a driver OS, this would be fine, if you want to run applications as well there would be a tradeoff between how much you map to Linux and how much to Xen domains.

What aspects of performance under Xen are you finding unacceptable?

I generally find performance acceptable, but as I said there are cases where there appears to be some friction against the goals of Xen (driver isolation) and the goals of the application (throughput, low latency).

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.

I would argue that you could get the same level of isolation (except from driver isolation) if you merge the two, while achieving the same IO performance as the monolithic model, and still be able to reuse existing driver code.

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.

It would still be interesting to reuse existing Xen guestOS ports on top of different hypervisor implementations.

Jacob


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

<Prev in Thread] Current Thread [Next in Thread>