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
> 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
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.
M.A. Williamson
2004-Dec-30 14:33 UTC
Re: [Xen-devel] isa_bus_to_virt_needs_PRIVILEGED_BUILD
> 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
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.
M.A. Williamson
2004-Dec-31 15:34 UTC
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel