On Sun, Oct 11, 2015 at 11:12:14AM +0300, Avi Kivity wrote: > > Mixing no-iommu and secure VFIO is > >also unsupported, as are any VFIO IOMMU backends other than the > >vfio-noiommu backend. Furthermore, unsafe group files are relocated > >to /dev/vfio-noiommu/. Upon successful loading in this mode, the > >kernel is tainted due to the dummy IOMMU put in place. Unloading of > >the module in this mode is also unsupported and will BUG due to the > >lack of support for unregistering an IOMMU for a bus type. > > I did not see an API for detecting whether memory translation is provided or > not. We can have the caller guess this by looking at the device name, or by > requiring the user to specify this, but I think it's cleaner to provide > programmatic access to this attribute.
It seems that caller can just check for VFIO_NOIOMMU_IOMMU. Isn't this why it's there? VFIO_IOMMU_MAP_DMA, VFIO_IOMMU_ENABLE and VFIO_IOMMU_DISABLE will probably also fail ... -- MST -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/