Re: [Xen-devel] run real drivers in differnt domains

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2007-12-13 at 07:08 -0800, Phani Babu Giddi wrote:
> Hi Ian,
>  
> Looks like this pass-through will work for devices on the PCI bus. But
> what about devices that are not on the PCI bus. I was going through
> one of the threads which talks about differences between xen 1.2 and
> 2.0 drivers. Where it mentions it possible to have such drivers. Is
> this possible with Xen 3.0 also ?

I don't think so, your choices are basically PV front/back virtual
devices (like we have for net, block and a couple of others) or PCI
passthrough of a physical PCI device.

What type of device are you dealing with?

Ian.

>  
> Regards,
> Phani
> Re: Xen 1.2 vs 2.0 device drivers
> 
>                           Subject: 
> Re: Xen 1.2 vs 2.0 device drivers
>                           List-id: 
> List for Xen developers
> <xen-devel.lists.sourceforge.net>
> >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.
> 
> 
> 
> 
> 
> On Dec 13, 2007 1:43 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
>         
>         On Wed, 2007-12-12 at 20:39 -0800, Phani Babu Giddi wrote:
>         > Hello All,
>         >
>         > I want to run 'real device drivers' I mean native drivers
>         (ofcourse
>         > recompiled for xen) as part of the two guests (Linux OS).
>         These 
>         > drivers will be accessing seperate devices and will not be
>         shared by
>         > guests. Do you think this configuration is possible ? I am
>         referring
>         > to a system with just PV and no HVM.
>         
>         
>         Sounds like you need the PV PCI pass-through functionality 
>         (pcifront/pciback). This will allow you to assign a PCI device
>         to a domU
>         instead of dom0.
>         
>         http://www.wlug.org.nz/XenPciPassthrough looks like a
>         reasonable doc, 
>         you should also search the list archives.
>         
>         Ian.
>         
> 


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