On Sun, 2019-04-07 at 17:31 -0600, Alex Williamson wrote: > It's not possible to do what you want with this configuration. An IOMMU > group represents the smallest set of devices that are isolated from > other sets of devices and is also therefore the minimum granularity we > can assign devices to userspace (ex. QEMU). The kernel reacts to > breaking the isolation of the group with a BUG_ON. If you managed not > to hit the BUG_ON here, you'd hit the BUG_ON in vfio code when the loss > of isolation is detected there. IOMMU groups are formed at the highest > point in the topology which guarantees isolation. This can be > indicated either via native PCIe ACS support or ACS-equivalent quirks > in the code. If the root port provides neither of these, then all > devices downstream are grouped together as well as all peer root ports > in the same PCI slot and all devices downstream of those. If a > multifunction endpoint does not provide ACS or equivalent quirks, the > functions will be grouped together. Not all endpoint devices or systems > are designed for minimum possible granularity. You can learn more > here[1]. Thanks, > > Alex > > [1] http://vfio.blogspot.com/2014/08/iommu-groups-inside-and-out.html
Hi Alex, Thank you for the detailed reply. The background information you provided makes it very clear why the devices I mentioned in my e-mail ended up in the same IOMMU group. But it seems that I was not clear enough in my original e-mail. My concern is that a user space action (modprobe) should never trigger a kernel BUG(). Is there any way to make sure that the sequence of actions I performed causes modprobe to fail with an error code instead of triggering a kernel BUG()? Thanks, Bart.
_______________________________________________ iommu mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/iommu
