Dear Alex, First, thank you for your write-up on the blog, that was very helpful. And I'm afraid that you're already bored of repeating the same answer again and again. :-)
2016-03-27 0:15 GMT+09:00 Alex Williamson <alex.l.william...@gmail.com>: > The grouping occurs the way it does because 00:02.* is a multifunction > device. Without native hardware support for ACS on those functions, we must > assume that routing within the multifunction device can result in non-IOMMU > translated peer-to-peer DMA between the downstream endpoints. You can use > the ACS override patch, but the reason that patch is not upstream is because > it is potentially unsafe, you may be declaring isolation where none really > exists and the VMs could interact with each other in unexpected ways. The > only real solution to enabling assignment of these devices is to work with > AMD to determine whether this internal re-routing is possible and if not, > add quirks to the kernel to expose the devices as isolated. Thanks, > > Alex I'm now wondering how it should be going on when we want to "work with" AMD (or other vendors). Do you mean that we need some acquaintances in AMD who can provide us a detailed spec document on AMD's PCI bridge [1022:156b] in this case, or confirm its behaviors? According to http://linux-hardware.org/index.php?id=pci:1022-156b the bridge seems a generic PCIe switch commonly found in AMD APU based cheap notebooks, used to connect various devices including wired/wireless networking, card readers, GPU etc. So I personally think it's likely to have the local re-routing capability which is unconfigurable and downstream devices cannot be isolated at all. What are your thoughts on that? Regards, -- YAEGASHI Takeshi <yaega...@debian.org> _______________________________________________ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users
