http://bugzilla.novell.com/show_bug.cgi?id=573311
http://bugzilla.novell.com/show_bug.cgi?id=573311#c2
--- Comment #2 from mail ignored <0.bugs.only.0@gmail.com> 2010-01-25 16:11:38 UTC ---
worth mentioning, from the related thread @ xen-devel,
http://lists.xensource.com/archives/html/xen-devel/2010-01/msg00870.html
On Sun, Jan 24, 2010 at 5:44 PM, Weidong Han
I think this is not a bug. pls note that the devices behind PCIe-to-PCI/PCI-x bridge or Conventional PCI bridge can only be collectively assigned to a single domain, because the source-id in DMA requests is not device's bdf. Pls refer to section 3.6.1 in VT-d spec. What's more, FLR is required to make sure the device in a correct status before assignment, and some devices need to reset secondary bus to reset the device which results in all the devices behind same PCIe-to-PCI/PCI-x bridge or Conventional PCI bridge be reset. In your case, you need to hide all NICs (04:06.0 and 04:07.0) behind the same bridge, and assign them together to a guest. or you can set "pci-passthrough-strict-check no" in /etc/xen/xend-config.sxp and restart xend to loose the check in xend, but in this way you should be aware of potential issues (e.g. assigned device doesn't work).
the 'set "pci-passthrough-strict-check no" in /etc/xen/xend-config.sxp' option is a xen 4.0 option ( on my sys, atm, Xen4 Dom0 boots fine, but booting DomUs under Xen 4.0 is non-functional :-/ ) that, iiuc, effects a similart workaround to that offered above. i'm sure the technical discussion above has merit, but ferreting out the issues of FLR & diving into the VT-d spec are not exactly user-friendly. this really needs either a fix or some clear discussion/explanation ... reading @ http://www.novell.com/documentation/sles11/book_xen/?page=/documentation/sle... implies "can't be done" ... if a fix _really_ isn't doable, at least, seems reasonable to provide a functionally-equivalent workaround in xen 3x to that in xen 4x, with similar warnings/explanation in docs -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.