RE: [Xen-users] Device Drivers in xen, looking also for a white book about how xen works exactly‏

["Venefax" <venefax@xxxxxxxxx>]

Your explanation misses to describe the difference between fully-virtualized
VM's and Paravirtualized ones, and why the performance of the later is much,
much better.
Please kindly continue. You are doing a great job summarizing the ongoing
discussion in the science and art of virtualization.

-----Original Message-----
From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Mark Williamson
Sent: Sunday, March 01, 2009 11:39 AM
To: xen-users@xxxxxxxxxxxxxxxxxxx
Cc: Patrick Archibal
Subject: Re: [Xen-users] Device Drivers in xen, looking also for a white
book about how xen works exactly‏

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&t
arget=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


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