Re: [Xen-devel] Xen 1.2 vs 2.0 device drivers

[Steven Hand <Steven.Hand@xxxxxxxxxxxx>]

>Hi, looking at the 2004-xen-ols-pdf papers's xen 2.0 Architecture fig 
>vs. the 1.2 fig, what is the
>differences between the device drivers? It seems like the drivers for 
>1.2 is ported to function in the
>paravirtual environment, but what is the deal with the 2.0 Front-end 
>and Vanilla device drivers?
>
>Fig 2.0 also has three red arrows, one from the 2.4 kernel to the HW 
>layer and two from the domain 0. What does
>this mean in contrast to fig. 1.2 ?

In 1.2, the "real" device drivers were part of Xen. Device drivers in 
guest OSes were 'virtual' device drivers that actually just talked to 
Xen to get anything done. 

In 2.0, the "real" device drivers run in one or more privileged guest 
OSes. Xen only deals with the timer (APIC) hardware, the low-level 
parts of interrupt dispatch, and some parts of the device probing 
functionality. Essentially linux device drivers (or BSD ones for that
matter) can run unmodified in a guest OS which, among other things, gives
us a lot more device support. 

Many devices (especially network and disk) are shared between guest OSes
but there is only ever one "real" device driver. To make this sharing 
work, a privileged guest also includes a "back-end" driver for every real
hardware device. All unprivileged guests wishing to share the device 
include a "front-end" driver. Both of these "drivers" are actually virtual; 
they do not directly talk to the hardware. Instead they are connected 
together using a device channel -- essentially a general means of communication
between different virtual machines. 

So if e.g. an unprivileged dom1 wants to share a real e1000 network card, 
the setup might be: 

     dom1 front-end driver -> dom0 back-end driver -> dom0 e1000 driver. 

The last driver is a "vanilla" linux device driver meaning that it's 
source code is identical to that in the regular linux kernel. The front-end
and back-end drivers are new. 

The lines in the figure connecting domains together represent the 
device channels that allow domains to talk to one another. 

The lines in the figure going from a domain 'through' xen represent the
way in which a suitably privileged domain can be given direct access to
[a subset of] the real hardware. 


You may find the our "Reconstructing I/O" paper gives a clearer description
of all of this. 


cheers,

S.