...

(tho' all of this could be avoided if y'all would just compile back in -- as opposed to module -- the pciback support)

Why? What happens when you load the module?

@boot, grub-defined kernel-xen options for pci-passthrough fail, reporting @dmesg, Unknown boot option `pciback.permissive': ignoring Unknown boot option `pciback.hide=(##:##.#)(##:##.#)': ignoring to fix (fairly widely discussed in xen- and RH-lands) the pciback (CONFIG_XEN_PCIDEV_BACKEND) module must be compiled into the dom0 kernel, & the pcifront (CONFIG_XEN_PCIDEV_FRONTEND) module must be compiled into the domU kernel or, if using a single/unified kernel-xen, then both must be compiled in. and, as you can see, in release, grep PCIDEV /boot/config-2.6.25.4-2-xen CONFIG_XEN_PCIDEV_FRONTEND=y # CONFIG_XEN_PCIDEV_FE_DEBUG is not set CONFIG_XEN_PCIDEV_BACKEND=m <------ CONFIG_XEN_PCIDEV_BACKEND_VPCI=y # CONFIG_XEN_PCIDEV_BACKEND_PASS is not set # CONFIG_XEN_PCIDEV_BACKEND_SLOT is not set # CONFIG_XEN_PCIDEV_BACKEND_CONTROLLER is not set # CONFIG_XEN_PCIDEV_BE_DEBUG is not set that's not the case. so as to avoid that and any add'l module-vs-compile "surprises" i'm trying to "de-modularize" xen, ------------------------------------------ [*] Privileged Guest (domain 0) <*> Backend driver support <*> Block-device backend driver <*> Block-device tap backend driver <*> Network-device backend driver [ ] Pipelined transmitter (DANGEROUS) <*> Network-device loopback driver <*> PCI-device backend driver PCI Backend Mode (Virtual PCI) ---> [*] PCI Backend Debugging <*> TPM-device backend driver <*> Block-device frontend driver <*> Network-device frontend driver <*> Network-device frontend driver acceleration for Solarflare NICs <*> User-space granted page access driver <*> Framebuffer-device frontend driver <*> Keyboard-device frontend driver [*] Xen virtual console [*] Scrub memory before freeing it to Xen [ ] Disable serial port drivers <*> Export Xen attributes in sysfs Xen version compatibility (3.0.4 and later) ---> ------------------------------------------ and also (haven't gotten there yet ...), build a dual-use kernel (Dom0 & DomU), which I think requires also, CONFIG_XEN_PRIVILEGED_GUEST=y --- # CONFIG_XEN_UNPRIVILEGED_GUEST is not set +++ CONFIG_XEN_UNPRIVILEGED_GUEST=y but 'make menuconfig' seems to not allow both. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

On Wed, May 21, 2008 at 02:38:35PM -0700, snowcrash+opensuse wrote:

fyi,

http://www.cl.cam.ac.uk/research/srg/netos/xen/readmes/user/ ... 5.3.1.1 Compile-Time Setup To use this functionality, ensure that the PCI Backend is compiled in to a privileged domain (e.g. domain 0) and that the domains which will be assigned PCI devices have the PCI Frontend compiled in. In XenLinux, the PCI Backend is available under the Xen configuration section while the PCI Frontend is under the architecture-specific "Bus Options" section. You may compile both the backend and the frontend into the same kernel; they will not affect each other.

If this is a problem, please file a bug and our Xen developers can either give the rationale for why it is not built in, or they can fix the kernel config. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org

nm on this one ... seems that zypper remove linux-kernel-headers kernel-xen kernel-source was not sufficient, as /usr/src/ was not 'cleaned', leaving references to *xenCUSTOM* in /usr/src/linux-... an additional, rm -rf /usr/src/linux* zypper install -y gcc make patch ncurses-devel before reinstalling from fresh rpm's gets me back to a clean starting point. continuing on now ... -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org