3/3 Fix [ia64] PV driver domains - ugly python hacks
RFC PATCH 1/1 3/3 Fix [ia64] PV driver domains - ugly python hacks
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.
--
tools/python/xen/xend/server/pciif.py +5 -3
@@ -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" \ )%(dev.name)) - 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." % dev.name) 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.
Quoted 18 lines · Alex Williamson
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.
Quoted 5 lines
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 <[email protected]>
Given that iommu is disabled on x86 by default,
this functional regression is accidental, I guess.
I think a sort of this patch is necessary for the next release. (at least for IA64)
thanks,
Signature · 1 line
yamahata
Quoted 10 lines · Isaku Yamahata
Quoted 5 lines
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 <[email protected]>Given that iommu is disabled on x86 by default,
this functional regression is accidental, I guess.
I think a sort of this patch is necessary for the next release. (at least for IA64)
This patch is a fine band-aid for now for 3.3 release. I'll apply it.
Thanks,
Keir