Re: [PATCH] vfio: Include No-IOMMU mode

[Alex Williamson <alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

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-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
> 
> 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,

Alex