On Sun, 2015-10-11 at 11:12 +0300, Avi Kivity wrote: > > On 10/09/2015 09:41 PM, Alex Williamson wrote: > > There is really no way to safely give a user full access to a PCI > > without an IOMMU to protect the host from errant DMA. There is also > > no way to provide DMA translation, for use cases such as devices > > assignment to virtual machines. However, there are still those users > > that want userspace drivers under those conditions. The UIO driver > > exists for this use case, but does not provide the degree of device > > access and programming that VFIO has. In an effort to avoid code > > duplication, this introduces a No-IOMMU mode for VFIO. > > > > This mode requires enabling CONFIG_VFIO_NOIOMMU and loading the vfio > > module with the option "enable_unsafe_pci_noiommu_mode". This should > > make it very clear that this mode is not safe. In this mode, there is > > no support for unprivileged users, CAP_SYS_ADMIN is required for > > access to the necessary dev files. > > CAP_SYS_RAWIO seems a better match (in particular, it allows access to > /dev/mem, which is the same thing).
Sure, that seems reasonable. > > 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. The VFIO user can probe and needs to set the IOMMU model in use before they can access a device file descriptor. In this mode, the VFIO_NOIOMMU_IOMMU is the only model available, which as proposed here provides no translation, and in fact no mapping ioctls. Thanks, Alex -- 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/
