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: "Jacob Gorm Hansen" <jacobg@xxxxxxx>, "Kip Macy" <kmacy@xxxxxxxxxxx>
Subject: RE: [Xen-devel] Xen as a kernel module
From: "Neugebauer, Rolf" <rolf.neugebauer@xxxxxxxxx>
Date: Wed, 26 Jan 2005 02:34:42 -0000
Cc: <Xen-devel@xxxxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 26 Jan 2005 02:35:16 +0000
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
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>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
Thread-index: AcUDSxfKm/KkR5QuTd+zk04EKZ903gAAI43A
Thread-topic: [Xen-devel] Xen as a kernel module

> -----Original Message-----
> From: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:xen-devel-
> admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Jacob Gorm Hansen
> Sent: 26 January 2005 02:00
> To: Kip Macy
> Cc: Xen-devel@xxxxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] Xen as a kernel module
> 
> Kip Macy wrote:
> > I'm obviously partisan, but I think that would largely defeat the
> > privilege de-coupling that they're trying to achieve. Not to mention
> > nullifying the notion of a driver domain.
> 
> Is anyone actually using driver domains, other than dom0? It would be
> really cool if hardware vendors started shipping drivers in Xen-VM
> format, but until that happens I do not see much motivation for having
> multiple full Linuxes around just to achieve a limited amount of
> isolation.

I don't think many people currently use separate driver domains and most
people run all their device drivers in dom0 and export them from there.

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.

The interfaces exported by Xen (for PCI config space, IO register
access, and interrupts) should be generic enough to support other OSes
as driver domains and the virtual device interfaces should be easily
implementable in other OSes too. Again, I think it would be foolish to
limit ourselves to Linux in this regard as your original post seems to
suggest. I think it would be great to see other OSes being used as
driver domains.

> It is no secret that I much preferred the old and simpler model, but I
> understand that noone likes having to port drivers, and I guess this
is
> one reason for the current state of things. With Xen inside the host
OS
> kernel, you would get the performance of the old model, and the ease
of
> development of the new model, plus potentially the option of running
Xen
> on millions of Windows-desktops (I am sure the Silicon Valley VCs
would
> love to hear that ;-)).
> 
> With all the OSes currently ported to Xen, the Xen hypercall interface
> could become a de-facto standard for paravirtualized OSes, especially
if
> Xen were able to run on top of Windows as well as on top of Linux.

I think it would be harder to come up with OS agnostic/generic
interfaces for Xen to be used inside a host OS (essentially sliding Xen
underneath a OS) than with generic abstractions which a OS can
use...plus there is the privilege decoupling issue Kip already raised. 

The current plan to move some of the platform init code out of Xen into
a VM will certainly make this slightly more complicated (eg having the
IOAPIC initialized by a VM and then handing control back to Xen) but I
hope we will come up with a generic interface for Xen to deal with
possibly different OSes to perform this task. At least that's something
I am advocating.

Rolf



> 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


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