On Mon, 2015-11-16 at 19:12 +0200, Avi Kivity wrote: > On 11/16/2015 07:06 PM, Alex Williamson wrote: > > On Wed, 2015-10-28 at 15:21 -0600, Alex Williamson wrote: > >> There is really no way to safely give a user full access to a DMA > >> capable device without an IOMMU to protect the host system. There is > >> also no way to provide DMA translation, for use cases such as device > >> assignment to virtual machines. However, there are still those users > >> that want userspace drivers even 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 building VFIO with CONFIG_VFIO_NOIOMMU and enabling > >> the "enable_unsafe_noiommu_mode" option on the vfio driver. This > >> should make it very clear that this mode is not safe. Additionally, > >> CAP_SYS_RAWIO privileges are necessary to work with groups and > >> containers using this mode. Groups making use of this support are > >> named /dev/vfio/noiommu-$GROUP and can only make use of the special > >> VFIO_NOIOMMU_IOMMU for the container. Use of this mode, specifically > >> binding a device without a native IOMMU group to a VFIO bus driver > >> will taint the kernel and should therefore not be considered > >> supported. This patch includes no-iommu support for the vfio-pci bus > >> driver only. > >> > >> Signed-off-by: Alex Williamson <alex.williamson at redhat.com> > >> --- > >> > >> This is pretty well the same as RFCv2, I've changed the pr_warn to a > >> dev_warn and added another, printing the pid and comm of the task when > >> it actually opens the device. If Stephen can port the driver code > >> over and prove that this actually works sometime next week, and there > >> aren't any objections to this code, I'll include it in a pull request > >> for the next merge window. MST, I dropped your ack due to the > >> changes, but I'll be happy to add it back if you like. Thanks, > >> > >> Alex > >> > >> drivers/vfio/Kconfig | 15 +++ > >> drivers/vfio/pci/vfio_pci.c | 8 +- > >> drivers/vfio/vfio.c | 186 > >> ++++++++++++++++++++++++++++++++++++++++++- > >> include/linux/vfio.h | 3 + > >> include/uapi/linux/vfio.h | 7 ++ > >> 5 files changed, 209 insertions(+), 10 deletions(-) > > FYI, this is now in v4.4-rc1 (the slightly modified v2 version). I want > > to give fair warning though that while we seem to agree on this idea, it > > hasn't been proven with a userspace driver port. I've opted to include > > it in this merge window rather than delaying it until v4.5, but I really > > need to see a user for this before the end of the v4.4 cycle or I think > > we'll need to revert and revisit for v4.5 anyway. I don't really have > > any interest in adding and maintaining code that has no users. Please > > keep me informed of progress with a dpdk port. Thanks, > > > > > > Thanks Alex. Copying the dpdk mailing list, where the users live. > > dpdk-ers: vfio-noiommu is a replacement for uio_pci_generic and > uio_igb. It supports MSI-X and so can be used on SR/IOV VF devices. > The intent is that you can use dpdk without an external module, using > vfio, whether you are on bare metal with an iommu, bare metal without an > iommu, or virtualized. However, dpdk needs modification to support this.
Still no users for this that I'm aware of. I'm going to revert this in rc5 unless something changes. Thanks, Alex
