isa_bus_to_virt_needs_PRIVILEGED_BUILD

isa_bus_to_virt_needs_PRIVILEGED_BUILD

[Ron Arts]

[-- Attachment #1: Type: text/plain, Size: 1059 bytes --]

Hi,

What does this mean? Having read the FAQ I can guess what
it means, but will this be solved eventually?

(I am trying to enable i2c in a -xenU domain)

   CC      arch/xen/i386/mm/ioremap.o
arch/xen/i386/mm/ioremap.c: In function `__ioremap':
arch/xen/i386/mm/ioremap.c:144: error: 
`isa_bus_to_virt_needs_PRIVILEGED_BUILD' undeclared (first use in this 
function)
arch/xen/i386/mm/ioremap.c:144: error: (Each undeclared identifier is 
reported only once
arch/xen/i386/mm/ioremap.c:144: error: for each function it appears in.)
arch/xen/i386/mm/ioremap.c: In function `bt_ioremap':
arch/xen/i386/mm/ioremap.c:280: error: 
`isa_bus_to_virt_needs_PRIVILEGED_BUILD' undeclared (first use in this 
function)
make[4]: *** [arch/xen/i386/mm/ioremap.o] Error 1
make[3]: *** [arch/xen/i386/mm] Error 2
make[3]: Leaving directory `/root/xen-2.0/linux-2.6.9-xenU'
make[2]: *** [build] Error 2
make[2]: Leaving directory `/root/xen-2.0'
make[1]: *** [linux-2.6-xenU-build] Error 2
make[1]: Leaving directory `/root/xen-2.0'
make: *** [kernels] Error 2

Thanks,
Ron

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3228 bytes --]

Re: isa_bus_to_virt_needs_PRIVILEGED_BUILD

[Keir Fraser]

> 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

Re: isa_bus_to_virt_needs_PRIVILEGED_BUILD

[Ron Arts]

[-- Attachment #1: Type: text/plain, Size: 1482 bytes --]

This is standard Xen 2.0, downloaded from:

http://www.cl.cam.ac.uk/Research/SRG/netos/xen/downloads/xen-2.0.1-src.tgz

Before I enabled i2c everything worked fine, but I have been
trying to assign hardware to specific domains.

Excluding pci from domain 0 works fine, apart from the documentation
errors, haven't tried adding the hidden pci card to another domain.
I was getting to that, when this error cropped up.

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).

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
> 

-- 
Netland Internet Services
bedrijfsmatige internetoplossingen

http://www.netland.nl   Kruislaan 419              1098 VA Amsterdam
info: 020-5628282       servicedesk: 020-5628280   fax: 020-5628281

Op dit bericht is de volgende disclaimer van toepassing:
http://www.netland.nl/maildisclaimer

Oxymoron: Tax Return.

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3228 bytes --]

Re: isa_bus_to_virt_needs_PRIVILEGED_BUILD

[M.A. Williamson]

> 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

Re: isa_bus_to_virt_needs_PRIVILEGED_BUILD

[Ron Arts]

[-- Attachment #1: Type: text/plain, Size: 1845 bytes --]

Okay,

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).

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.

But what is a backend domain, and how does it connect
to a driver domain?

Is that described somewhere?

Ron


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

-- 
Netland Internet Services
bedrijfsmatige internetoplossingen

http://www.netland.nl   Kruislaan 419              1098 VA Amsterdam
info: 020-5628282       servicedesk: 020-5628280   fax: 020-5628281

Op dit bericht is de volgende disclaimer van toepassing:
http://www.netland.nl/maildisclaimer

RENTAL CAR: The only *TRUE* all-terrain vehicle.

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3228 bytes --]

Re: isa_bus_to_virt_needs_PRIVILEGED_BUILD

[M.A. Williamson]

> 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