Alex Williamson
2008-Aug-07 20:20 UTC
[Xen-ia64-devel] [PATCH][RFC] 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.
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
--
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" \
)%(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.
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Isaku Yamahata
2008-Aug-08 05:19 UTC
[Xen-ia64-devel] Re: [Xen-devel] [PATCH][RFC] 3/3 Fix [ia64] PV driver domains - ugly python hacks
On Thu, Aug 07, 2008 at 02:20:34PM -0600, Alex Williamson wrote:> > 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@hp.com>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, -- yamahata _______________________________________________ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Keir Fraser
2008-Aug-08 08:08 UTC
Re: [Xen-devel] [PATCH][RFC] 3/3 Fix [ia64] PV driver domains - ugly python hacks
On 8/8/08 06:19, "Isaku Yamahata" <yamahata@valinux.co.jp> wrote:>> 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@hp.com> > > 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel