On Sun, Oct 11, 2015 at 12:03:17PM +0300, Avi Kivity wrote: > > > On 10/11/2015 11:57 AM, Michael S. Tsirkin wrote: > >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? > > That's just means the capability is there, not that it's active.
Well it's currently exactly the same. I guess you can check the return value of VFIO_SET_IOMMU as well. > But since you must pass the same value to open(), you already know that > you're using noiommu. > > >VFIO_IOMMU_MAP_DMA, VFIO_IOMMU_ENABLE and VFIO_IOMMU_DISABLE > >will probably also fail ... > > > > Don't you have to call MAP_DMA to pin the memory? Well check it out - the patch in question doesn't implement this ioctl. In fact it doesn't implement anything except CHECK_EXTENSION. And this makes sense to me: MAP_DMA maps a virtual address to io address, and that doesn't work for the dummy iommu. You can pin memory using many other ways, including mlock and hugetlbfs. -- MST _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
