> Thanks for the reply. Couple of queries...
> 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
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
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
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.
> On Dec 8, 2007 9:57 AM, Mark Williamson <mark.williamson@xxxxxxxxxxxx>
> > > 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