Re: kernel BUG at drivers/iommu/intel-iommu.c:608

[Bart Van Assche <bvanassche-HInyCGIudOg@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1815 bytes --]

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.

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]