This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-ia64-devel] [PATCH][RFC] 3/3 Fix [ia64] PV driver domains - ugly py

To: xen-ia64-devel <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-ia64-devel] [PATCH][RFC] 3/3 Fix [ia64] PV driver domains - ugly python hacks
From: Alex Williamson <alex.williamson@xxxxxx>
Date: Thu, 07 Aug 2008 14:20:34 -0600
Cc: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 07 Aug 2008 13:20:34 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: OSLO R&D
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
x86 IOMMU support added a lot of assumptions about what PCI buses look
like and where to find bridge devices.  On ia64, we don't yet have
virtualization friendly IOMMUs, so for the moment, we just want to keep
"unsafe" PV PCI pass through working as well as it did in Xen 3.2.
Looking at the code, it almost seems like x86 has thrown out support for
the old style driver domain.  Things that don't necessarily work on
every PCI compliant architecture:

      * You can't assume that just because there's a device at 01:01.0
        that there's also a bridge at 01:00.0 and blow-up when you don't
        find it.  On HP ia64 boxes, PCI root bridges are not
        necessarily exposed as a PCI device.  This pretty much means we
        can't call into any of the "FLR" code paths.
      * BAR alignment: it's hard to have BAR alignment when your page
        size is 16k.  This wasn't a requirement for previous PV driver
        domains, so I assume it's only for IOMMU support.

This is ugly, so I'm open to suggestions.  It seems that all of these
architecture checks could be replaced by checking some "iommu_present"
variable to test whether the extra requirements are necessary.

Signed-off-by: Alex Williamson <alex.williamson@xxxxxx>

diff -r eff5fcfa69bc tools/python/xen/xend/server/pciif.py
--- a/tools/python/xen/xend/server/pciif.py     Wed Aug 06 15:19:13 2008 +0100
+++ b/tools/python/xen/xend/server/pciif.py     Thu Aug 07 13:51:26 2008 -0600
@@ -21,6 +21,7 @@ import time
 import time
 from xen.xend import sxp
+from xen.xend import arch
 from xen.xend.XendError import VmError
 from xen.xend.XendLogging import log
@@ -284,12 +285,13 @@ class PciController(DevController):
                     "bind your slot/device to the PCI backend using sysfs" \
-        if dev.has_non_page_aligned_bar:
+        if dev.has_non_page_aligned_bar and arch.type != "ia64":
             raise VmError("pci: %: non-page-aligned MMIO BAR found." % 
         self.CheckSiblingDevices(fe_domid, dev)
-        dev.do_FLR()
+        if arch.type != "ia64":
+            dev.do_FLR()
         PCIQuirk(dev.vendor, dev.device, dev.subvendor, dev.subdevice, domain, 
                 bus, slot, func)
@@ -395,7 +397,7 @@ class PciController(DevController):
                                     ' the same guest with %s'
                                 raise VmError(err_msg % (f, dev.name))
             elif dev.dev_type == DEV_TYPE_PCI:
-                if dev.bus == 0:
+                if dev.bus == 0 or arch.type == "ia64":
                     if not dev.pci_af_flr:
                         # We cope with this case by using the Dstate transition
                         # method for now.

Xen-ia64-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>