Red Hat Bugzilla – Full Text Bug Listing
|Summary:||No "pciback.hide" kernel command line option|
|Product:||[Fedora] Fedora||Reporter:||JM <igeorgex>|
|Component:||xen||Assignee:||Juan Quintela <quintela>|
|Status:||CLOSED RAWHIDE||QA Contact:||Brian Brock <bbrock>|
|Version:||5||CC:||bstein, ddutile, deneault, gawain.lynch, gilboad, katzj, lannet, xen-maint|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2006-09-20 13:08:48 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:||200135|
Description JM 2006-04-12 20:30:57 EDT
Description of problem: I tried to assign a pci device direct to the guest system and because of that I used the kernel command line option "pciback.hide" but when I boot the system I get the message: Unknown boot option `pciback.hide=(05:00.0)': ignoring This way I can't pass the device to the guest system. Is it possible that the pciback.hide option is not part of the XEN-Kernel of FC5? Version-Release number of selected component (if applicable): kernel-xen0-2.6.16-1.2080_FC5 kernel-xenU-2.6.16-1.2080_FC5
Comment 1 JM 2006-04-12 20:32:47 EDT
I forgot, its's a x86_64 system.
Comment 2 JM 2006-04-20 09:43:38 EDT
It's now Kernel 2.6.16-1.2096_FC5xen0 and still the same problem: Unknown boot option `pciback.hide=(05:00.0)': ignoring
Comment 3 lannet 2006-04-29 20:25:46 EDT
I think you will find that this is because XEN_PCI_BACKEND (or similar) is not configured into the xen0 kernel by default. Perhaps both the BACKEND and the FRONTEND should be compiled into xen0 by default - the doco says that they do not conflict.
Comment 4 deneault 2006-05-23 16:55:56 EDT
I concur. Is it possible to get this compiled into the default kernel? I also have the x86_64 distro running 2.6.16-1.2122_FC5xen0 and get the same message.
Comment 5 Gilboa Davara 2006-06-22 05:08:04 EDT
I second the above. It was suggested (in the -devel list) that enabling CONFIG_XEN_PCIDEV_FRONTEND and CONFIG_XEN_PCIDEV_BACKEND breaks the TCP checksum and raises security concerns. Is there any documentation for such issues?
Comment 6 Gawain Lynch 2006-06-24 21:32:07 EDT
I have been working on building and testing kernels with PCI backend/frontend built in and have found the following issues: 1. There are possible security implications 2. xen-3.0.2-0.FC5.3 breaks `xm save' and `xm restore' for domU's that use the pci=[''] directive in the config file. 3. xen-3.0.2-3.FC5 breaks only `xm restore' 4. Breaks TCP checksums 5. kernel 2.6.17-1.2139_FC5 causes `kernel: xen_net: Memory squeeze in netback driver.' errors that quickly bring down dom0 Security Implications --------------------- The security concerns I mentioned on -devel are documented at http://www.cl.cam.ac.uk/Research/SRG/netos/xen/readmes/user/user.html#SECTION03620000000000000000 A summary of the points on that page are: 1. Without an IOMMU, a hardware device can DMA to memory regions outside of its controlling domain. 2. Shared buses are vulnerable to sniffing. 3. Devices which share interrupt lines can either prevent the reception of that interrupt by the driver domain or can trigger the interrupt service routine of that guest needlessly. 4. Devices may share the use of I/O memory address space. Problems with `xm save' & `xm restore' -------------------------------------- This has been brought up on xen-users and it looks to be partially fixed with the curent -unstalbe snapshot used in FC5 & rawhide. It can be worked around by commenting out `XENDOMAINS_MIGRATE' and `XENDOMAINS_SAVE' in /etc/sysconfig/xendomains. This just means that shutdown times for dom0 will be extended. TCP Checksums ------------- When I switched to using PCI backend drivers I found that my domU's could ping and be pinged but connection oriented connections would timeout. Looking at the output of `tcpdump -v -v -n -i ethX' showed the problem. A bit of searching not only led me to a better solution to my outdated firewall scripts but I also found mention of the problem at http://www.shorewall.net/XenMyWay.html#Domains under the 'Caution` heading. kernel 2.6.17-1.2139_FC5 ------------------------ I am still testing this issue. A possible solution is mentioned here http://lists.xensource.com/archives/html/xen-users/2006-02/msg00077.html
Comment 7 Gawain Lynch 2006-06-24 21:33:57 EDT
This bug should be against the kernel or kernel-xen component.
Comment 8 Gawain Lynch 2006-06-24 21:53:38 EDT
Created attachment 131493 [details] Patch to kernel-2.6.spec to enable testing of PCI backend/frontend This is just a simple patch for anyone that want to build their own kernel and have PCI backend/frontend drivers enabled. It is *not* proposed for inclusion, just to help testers of this functionality.
Comment 10 Gilboa Davara 2006-07-02 12:09:31 EDT
Created attachment 131854 [details] kernel-2.6.17-1.2139_FC5 build breakage log Gawain, Patch seems to break the 2139 kernel build. It fails on "drivers/net/b44.c:2152: error: implicit declaration of function 'dma_get_cache_alignment'". I tried adding my own patch which added "#include <asm/dma-mapping.h>" but it didn't help. What am I missing. Beware, once opened, logfile is big (>2MB).
Comment 11 Gawain Lynch 2006-07-02 19:38:36 EDT
Created attachment 131867 [details] Patch to kernel-2.6.spec to enable testing of PCI backend/frontend This one is against 2.6.17-1.2139. The previous patch was against 2133 and some of the symbols now appear in the config files. Works For Me(tm)
Comment 12 Gilboa Davara 2006-07-03 05:58:42 EDT
Gawain, Thanks for the help. .. but, no go. $ rpm -ivh ~/Download/kernel-2.6.17-1.2139_FC5.src.rpm $ cd ~/redhat/SPECS/ $ patch -p0 < ~/Download/kernel-2.6.17-1.2139.XenPCI.patch patching file kernel-2.6.spec $ rpmbuild -ba kernel-2.6.spec ... drivers/net/b44.c:2152: error: implicit declaration of function 'dma_get_cache_alignment' What am I missing?
Comment 13 Gawain Lynch 2006-07-03 07:37:14 EDT
Created attachment 131880 [details] Patch to kernel-2.6.spec to enable testing of PCI backend/frontend on x86_64 OK, I see from closer inspection of the log that you are building on x86_64 whereas poor old me is stuck on IA32 :-( For some reason the Broadcom 4400 driver won't build on x86_64, so I have another patch that just disables it. Ugly, but effetive. I think this is one for the kernel guys would otherwise need to look at.
Comment 14 Gilboa Davara 2006-07-03 15:21:33 EDT
Gawain, Thanks! Kernel builds just fine. I'll try the new kernel this week. G.
Comment 15 Gilboa Davara 2006-07-04 01:50:16 EDT
... Well, that joy was short lived. PCIBACKEND enabled kernel dies when xend is being started. I spews out a "Bridge firewalling registered" and hangs. No OOPS message, nothing. Couldn't find anything meaningful in /var/log/message and /var/log/xen*. Any use in reporting upstream?
Comment 16 Gawain Lynch 2006-07-04 01:56:08 EDT
I feel for you Gilboa. I tore many hairs out making this work too. At this point I have falled back to 2133 and xen-3.0.2-0.FC5.3, as 2139 gave me too many problems with PCI delegation. That ultimately might be the way to go for the time being. The orignal patch should have been against 2133 if you want to start from there.
Comment 17 Gilboa Davara 2006-07-04 04:40:55 EDT
OK. Good to know that I'm not alone. ;) I'll give 2133 a try. Thanks again for the help.
Comment 18 Stephen Tweedie 2006-09-20 13:08:48 EDT
All working on current rawhide: I've got this [root@guest3 ~]# /sbin/ifconfig eth1 eth1 Link encap:Ethernet HWaddr 00:13:20:F3:F8:56 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Base address:0x20e0 Memory:50200000-50220000 [root@guest3 ~]# /sbin/lspci 00:00.0 Ethernet controller: Intel Corporation 82566DC Gigabit Network Connection [root@guest3 ~]# running on a domU guest using kernel-2.6.17-1.2647.fc6xen for both domU and dom0.