> So far I thought the xen0 kernel was only to be used for the
> first domain (which is called domain 0 in the documentation,
> hence my confusion).
As you've probably discovered, the xenU kernel is included because it is
smaller (because it omits drivers for real hardware). You can use xen0
kernels in domains that talk to hardware (dom0, driver domains) AND in
unprivileged guests.
> After reading the docs more thoroughly, I discovered the
> concept of 'driver domains' which can be used as 'backends
> for other domains'.
>
> So, apparently you can use xen0 kernels more than
> once on a machine, and you can use them to support
> hardware.
Yup.
> But what is a backend domain, and how does it connect
> to a driver domain?
>
> Is that described somewhere?
OK, here's a quick rundown of the Xen device model: * domain 0 controls
real devices using direct hardware access * virtual devices in guest
domains are exported from domain 0 using shared memory communications * Xen
itself is unaware of the specifics of the virtual devices. All it knows /
cares about is that some domains are sharing memory (and using "event
channels" to send virtual interrupts) * the abstraction of virtual devices
is provided by two Linux kernel drivers:
1) the "backend" driver (usually in dom0) provides services to guest
domains by exporting virtual devices to them
2) the "frontend" driver (in the guest domain) communicates with the
backend driver in order to perform IO and provides the illusion of a
conventional device to the rest of the OS * when you create a domain, Xend
helps the guest's frontend drivers and the backend drivers in dom0 to
connect to each other. Once the guest is running, the drivers communicate
directly using shared memory.
The architecture is quite modular, so (in principle) you can run a driver
for each real network / block device in a separate domain, instead of all
in dom0. Each of these "driver domains" will control their device using
direct hardware access but can also run the appropriate backend driver so
that they can export device services to other domains. Xend can connect
each guest to any of these domains.
We restrict the hardware privileges of a driver domain so that it's less
liable to crash the system if it's buggy. It is possible to restart failed
driver domains and have the guest devices reconnect with only a few hundred
milliseconds loss of service.
In practice, there are some limitations on the configurations that Xend
will support. Not many people use driver domains right now, although it's
useful functionality we'd like to keep around and perhaps extend.
I believe there's a configuration option that allows you to specify which
backends the virtual devices of a guest should connect to. There's also an
option for configuring a domain to export devices (run the backend).
There's some detail on this in the configuration file documentation...
HTH,
Mark
> M.A. Williamson wrote:
> >> Does anyone know how I can detect if some hardware is actually assigned
> >> to some domain (apart from loading the device driver)? lspci
> >> does not work (/proc/bus/pci not present).
> >
> >
> > lspci should Just Work(TM). Are you using a xen0 kernel in that domain?
> > The xenU kernel doesn't have any PCI support.
> >
> > Cheers,
> > Mark
> >
> >> Ron
> >>
> >> PS: The doc error:
> >> pci_dom0_hide=(xx.xx.x)(yy.yy.y)... should be
> >> physdev_dom0_hide=(xx:xx.x)(yy:yy.y)...
> >>
> >>
> >> Keir Fraser wrote:
> >> >>Hi,
> >> >>
> >> >>What does this mean? Having read the FAQ I can guess what
> >> >>it means, but will this be solved eventually?
> >> > > > What version of Xen is this? Looking at ioremap.c I don't see
> >> how your
> >> > build can fail -- __ioremap() is conditional on
> >> > CONFIG_XEN_PHYSDEV_ACCESS, as is the definition of isa_bus_to_virt in
> >> > asm-xen/asm-i386/io.h. i.e., if isa_bus_to_virt is not defined, then
> >> > neither is __ioremap.
> >> > > -- Keir
> >> >
> >>
> >
>
>
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....
http://www.thinkgeek.com/sfshirt _______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel
smime.p7s (3.15 KB)