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

Re: [Xen-users] Device Drivers in xen, looking also for a white book abo

To: xen-users@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-users] Device Drivers in xen, looking also for a white book about how xen works exactly‏
From: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Date: Sun, 1 Mar 2009 16:39:11 +0000
Cc: Patrick Archibal <bugpb60@xxxxxxxxxxx>
Delivery-date: Sun, 01 Mar 2009 08:40:00 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <COL103-W558C9E449925AB4A16FCC2ABA80@xxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <COL103-W558C9E449925AB4A16FCC2ABA80@xxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.11.0 (Linux/2.6.27-11-generic; KDE/4.2.0; i686; ; )
Hi there,

> I want to know how it works on xen.
> I think that :
>
>  All drivers are in the hypervisor, when a guest requires to use a device, 
> guest uses drivers which has been rewriten for xen in order to contact the
> hypervisor. Then, the hypervisor which has all real drivers (not modified)
> call the real device ?

That's how Xen 1.x worked.  Porting drivers to Xen was ugly and time 
consuming, so we moved it to the other model you describe.  Let's call this 
approach #1.

> or that :
> The real device driver is contained in the dom0 system, the dom0 manage
> driver for all domU.

This is how Xen worked from Xen 2.x onwards.  Xen 3.x uses a very similar 
architecture but moves *even more* driver stuff into dom0.  Xen knows very 
little about devices.  Lets call this approach #2.

> I have three questions :
>
> 1 -  Which is the good scenario ? (if one is good ) :o)

As usual in Operating Systems (and everything else!) the answer is probably 
"It depends" ;-)

If you were making an embedded device, where you have a small selection of 
hardware to expect then it might make sense to take approach #1 and put the 
drivers in the hypervisor.

In Xen's case, the goal is to have a fairly small hypervisor but be able to 
run on a wide variety of PCs.  Running on a wide variety of PCs means that 
lots of drivers need to be available and the only sensible way to do this was 
to run the drivers in a Linux guest, instead of porting them all to Xen.

Another potentially benefit of approach #2 is that your device drivers are 
contained in VMs.  If you go a step further than what you described and make 
it possible to run drivers in domains *other* than dom0 then if a driver 
crashes, it can be killed and restarted.  You can't do this when the drivers 
are in the hypervisor itself (or dom0).

For Xen's purposes, approach #2 has been much better.  Microsoft's Hyper-V is 
taking this approach too, I believe.

Note, however, that VMware ESX - a *very* strong and successful product - uses 
approach #1 with great success.  Arguably Linux-based approaches like KVM use 
approach #1 also but the difference there is that *Linux is the hypervisor* so 
drivers do not need to be ported to it.  For this reason, approach #1 is not a 
disadvantage to them (it's even a strength!).

> 2 - If drivers for guests are rewritten to call hypervisor or dom0 instead
> of the device directly, who devellops driver ? (xen devellopers ? or
> developper for kernel mainline)

The Xen patches are designed so that the *real* device drivers work unmodified 
(they just need to be compiled for Xen).  To get device access to domUs, a set 
of "Virtual Device" drivers are written.  These are written by the Xen 
developers and are used to give network and block (and framebuffer) access to 
domUs.

> 3- Which is the real utility of dom0 system ? (just I/O and administration
> of virtual machines)

You can run what you want in dom0 - some people run X.org and use it as their 
"desktop" OS.  For a secure deployment you want a minimal set of drivers and 
administration tools in it.

> Last question, is someone have find a good white paper or doc which
> explains how xen works ? (and where i can find probably answers for my
> questions ??)

Look at these:
http://wiki.xensource.com/xenwiki/XenArchitecture?action=AttachFile&do=get&target=Xen+Architecture_Q1+2008.pdf
http://www.cl.cam.ac.uk/research/srg/netos/papers/2003-xensosp.pdf
http://www.cl.cam.ac.uk/netos/papers/2004-oasis-ngio.pdf
http://www.cl.cam.ac.uk/research/srg/netos/xen/architecture.html

"Xen and the art of virtualization" describes the Xen 1.x driver architecture 
but it is a useful guide to the rest of the system.  "Safe hardware access..." 
describes the newer architecture.



> Thanks for all this details.
> Best regards
>
> Patrick Archibal

Hope this helps,
Cheers!
Mark

> Inédit ! Des Emoticônes Déjantées! Installez les dans votre Messenger !
> http://www.ilovemessenger.fr/Emoticones/EmoticonesDejantees.aspx


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users