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
|
Home