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: "Neugebauer, Rolf" <rolf.neugebauer@xxxxxxxxx>
Subject: Re: [Xen-devel] Xen as a kernel module
From: Jacob Gorm Hansen <jacobg@xxxxxxx>
Date: Tue, 25 Jan 2005 19:12:15 -0800
Cc: Kip Macy <kmacy@xxxxxxxxxxx>, Xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 26 Jan 2005 03:15:09 +0000
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
In-reply-to: <39CC97884CA19A4D8D6296FE94357BCB0161A804@swsmsx404>
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: <39CC97884CA19A4D8D6296FE94357BCB0161A804@swsmsx404>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0 (X11/20050116)
Neugebauer, Rolf wrote:

However, I think it would be foolish to remove the ability to run
separate driver domains from Xen as it doesn't seem to add significant
overhead (over running them in Dom0) and it has the potential of being
extremely useful. You already mentioned the shipping of device drivers,
there might also some interesting security applications. We can
currently already provide some degree of isolation against device driver
bugs and for the DMA issue there are a number of known and existing
solutions (see eg the L4 OSDI device driver paper). The grant-table
design (unfortunately not fully implemented yet) with some form of
IO-MMU should provide the rest of the isolation.

First of all, my suggestion was to have this as a configuration option, or even a separate implementation, providing just the ability to host domUs. I am sure this is doable, as it seems to be what coLinux is doing with some success. I was not suggestion throwing away existing functionality, but to optimize for the common case, i.e. a single Linux providing all drivers.

Secondly, there have been repeated reports on this list of people having problems with lower performance in domU than in dom0, perhaps due to cheap hardware, perhaps just due to misconfiguration, and the figures on the Xen website have not been updated to reflect what the actual situation is, so I guess nobody knows what the overhead will look like for a specific type of application. I would worry about MPI-style jobs, where you need both low latency and high bandwidth networking, and where you are likely to fully utilize the TLBs as well. I cannot see how performance does not get hurt in this situation, when Xen needs to flush the TLB for every interrupt, or alternatively needs to bundle interrupts, thus increasing latency.

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