WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

Re: [Xen-users] Linux Device Drivers modified in Xen ?

> Thanks for the reply. Couple of queries...

Sure.

> 1. What happens in the case of a char driver, do I have to necessarily run
> it dom0? If so can a buggy driver bring down dom0 or other drivers ? I know
> dom0 is isolated but is it protected inside also.

With PCI passthrough you can run device drivers for PCI devices inside a 
domain other than dom0.  This provides dom0 some protection from driver 
malfunction.

You can also specify ioports, mmio ranges and IRQs that a guest can map to 
access legacy devices (serial devices, for instance).

The reason this is only partial protection for dom0, in general, is that if 
you have a DMA capable device there is not always a way to stop it using DMA 
to access any memory in the machine.  Intel and AMD are bringing out IOMMUs 
which allow this protection so that it'll be possible to (more or less) 
completely contain faults in domains with access to hardware devices.

If a domain (other than dom0) is running (for example) a block backend and it 
crashes, it is possible in principle to restart that domain and reconnect to 
all the frontend domains that were using it.  i.e. even though the backend 
crashes, the frontends are able to seamlessly recover once the backend 
reboots.  I say "in principle" because this used to work but I suspect it's 
not been tested in ages, so it may have broken!

> 2. Assuming that the char driver has been compiled against XenLinux and it
> is running in dom0 then what are the other modifications that I need to do
> in order to access it from guest OSs.

There's currently no general way to pass a char device through to a guest.  If 
people need to do this I usually recommend either domain-specific solution 
(e.g. run a backup daemon to provide shared access to a tape device) or 
consider giving that domU direct access to that hardware, making it a driver 
domain.

The flexibility in passing devices through keeps increasing though.  Once 
pvSCSI is in the tree you'll be able to pass through any SCSI-based device 
(block, character, whatever) to guests.

> 3. In general if XenLinux has a generic framework for block, net, and other
> bus drivers do guest OSs need to change worry about writing/modifying its
> native drivers ?

Under full virtualisation (HVM), Xen emulates a specific (although it can 
change a bit between releases) set of "real world" hardware.  If the guest OS 
supports that hardware then it can access the virtual block / net device 
regardless of the underlying hardware.  As long as the guest has drivers for 
the virtual hardware it doesn't matter what real hardware it's running on top 
of.

Under paravirtualisation (PV), guests use a standardised interface to talk to 
the virtual block and net devices.  This is also independent from the 
underlying hardware and should work regardless of what disks / network 
devices you actually have on the system.

In fact, the real source of block and net devices is completely invisible to 
the guest.  You can power down a guest that's using a disk partition, switch 
it to using an NBD network block device and (if you set it up right) the 
guest wouldn't notice the difference when you power it on again.

More concretely, you could run a domU which doesn't have as many hardware 
drivers as Linux, such as Plan 9 or even Solaris.  If you have a dom0 running 
Linux then the guest can run from any block / net hardware Linux can access - 
even if the guest OS on its own doesn't have a driver for it.

Cheers,
Mark

> Thanks,
> Phani
>
> On Dec 8, 2007 9:57 AM, Mark Williamson <mark.williamson@xxxxxxxxxxxx>
>
> wrote:
> > > I have spent enough time trying to find out if the native device
> > > drivers
> >
> > in
> >
> > > Linux need to be modified for it to work on Linux or not. I havent been
> > > able to find a specific answer, so I thought i will post a query on
> > > this list. So here are a list of some question that I have.
> > >
> > > 1. Will native Linux device drivers work when running on Zen VMM?
> >
> > The source code of native Linux drivers does not need to be modified for
> > use
> > in dom0 or a driver domain.  Occasionally a driver doesn't work because
> > of bugs / assumptions and these have to be fixed but usually well-written
> > drivers will Just Work when compiled against the XenLinux kernel and
> > loaded.
> >
> > You can't load a driver that was compiled against non-Xen Linux, but then
> > you
> > can't generally load drivers that were compiled against different Linuxes
> > anyhow, due to the lack of a stable ABI.
> >
> > > 2. Has XenSource or somebody have written the front end and back end
> >
> > driver
> >
> > > for every device driver in Linux ? Or is it that only for a limited set
> >
> > of
> >
> > > devices the front end and back end drivers were developed.
> >
> > The main front / back drivers available are block (should work with any
> > physical block device) and net (should work with any physical net
> > device).
> >
> > There's also a simple, low performance framebuffer front / back driver.
> >
> > There's some basic support for passing specific USB devices to HVM guests
> > in
> > the tree.  It's also possible to assign whole PCI devices to a PV guest
> > (or
> > HVM, in the unstable tree).  There's a pvSCSI driver in the works (you
> > can already access SCSI disks, this extends support to other
> > peripherals). These
> > techniques (do / will / should) allow you to pass devices into a guest
> > that
> > are not supported by the generic front / back device classes.
> >
> > > 3. Is there some kind of documentation availabl for writing split
> > > device drivers?
> >
> > There's some documentation in the interface manual in the source tree,
> > probably some on the wiki.  The code may also be helpful to read.
> >
> > The papers here
> > (http://www.cl.cam.ac.uk/research/srg/netos/xen/architecture.html) are
> > also
> > worth reading, especially "Safe Hardware Access with the Xen Virtual
> > Machine
> > Monitor" for a description of the IO architecture and "Xen and the Art of
> > Virtualization" for general Xen background.
> >
> > You can also ask technical questions about implementation on the
> > xen-devel mailing list.  The mailing list archive is possibly worth a
> > look too.
> >
> > Hope that helps,
> >
> > Cheers,
> > mark
> >
> > --
> > Dave: Just a question. What use is a unicyle with no seat?  And no
> > pedals! Mark: To answer a question with a question: What use is a
> > skateboard? Dave: Skateboards have wheels.
> > Mark: My wheel has a wheel!



-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

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

<Prev in Thread] Current Thread [Next in Thread>