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 DMAFYI, this is now in v4.4-rc1 (the slightly modified v2 version). I want
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@xxxxxxxxxx>
---
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(-)
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,