21 messages in com.xensource.lists.xen-develRe: [Xen-devel] Xen as a kernel module
FromSent OnAttachments
Jacob Gorm Hansen25 Jan 2005 17:23 
Kip Macy25 Jan 2005 17:32 
Jacob Gorm Hansen25 Jan 2005 17:59 
Neugebauer, Rolf25 Jan 2005 18:34 
Jacob Gorm Hansen25 Jan 2005 19:11 
Ronald G. Minnich25 Jan 2005 19:57 
Ronald G. Minnich25 Jan 2005 20:30 
Keir Fraser25 Jan 2005 23:54 
Steven Hand26 Jan 2005 00:41 
Ian Pratt26 Jan 2005 03:41 
Jacob Gorm Hansen26 Jan 2005 15:19 
Mark Williamson27 Jan 2005 05:24 
Mark Williamson27 Jan 2005 05:30 
Tobias Hunger27 Jan 2005 07:04 
Mark Williamson28 Jan 2005 10:31 
Jacob Gorm Hansen28 Jan 2005 12:09 
Ronald G. Minnich28 Jan 2005 12:59 
Jacob Gorm Hansen28 Jan 2005 15:16 
Ronald G. Minnich28 Jan 2005 15:26 
Jacob Gorm Hansen28 Jan 2005 15:28 
Adam Sulmicki28 Jan 2005 18:15 
Subject:Re: [Xen-devel] Xen as a kernel module
From:Jacob Gorm Hansen (jac@diku.dk)
Date:01/25/2005 07:11:53 PM
List:com.xensource.lists.xen-devel

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