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

Re: [Xen-devel] isa_bus_to_virt_needs_PRIVILEGED_BUILD

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@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel