|
xen-users
RE: [Xen-users] Device Drivers in xen, looking also for a white book abo
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
|
|
|
Home