[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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&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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |