public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: avi@scylladb.com, avi@cloudius-systems.com, gleb@scylladb.com,
	corbet@lwn.net, bruce.richardson@intel.com, mst@redhat.com,
	linux-kernel@vger.kernel.org, alexander.duyck@gmail.com,
	gleb@cloudius-systems.com, vladz@cloudius-systems.com,
	iommu@lists.linux-foundation.org, hjk@hansjkoch.de,
	gregkh@linuxfoundation.org
Subject: Re: [RFC PATCH 2/2] vfio: Include no-iommu mode
Date: Mon, 12 Oct 2015 08:56:07 -0700	[thread overview]
Message-ID: <20151012085607.2c64f98f@urahara> (raw)
In-Reply-To: <20151009184110.14752.53531.stgit@gimli.home>

On Fri, 09 Oct 2015 12:41:10 -0600
Alex Williamson <alex.williamson@redhat.com> 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.  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.
> 
> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>

Will this work for distro's where chaning kernel command line options
is really not that practical. We need to boot with one command line
and then decide to use IOMMU (or not) later on during the service
startup of the dataplane application. Recent experience is that IOMMU's
are broken on many platforms so the only way to make a DPDK application
it to write a test program that can be used to check if VFIO+IOMMU
works first.

Also, although you think the long option will set the bar high
enough it probably will not satisfy anyone. It is annoying enough, that
I would just carry a patch to remove it the silly requirement.
And the the people who believe
all user mode DMA is evil won't be satisfied either.

But I really like having the same consistent API for handling device
access with IOMMU and when IOMMU will/won't work.

  parent reply	other threads:[~2015-10-12 15:55 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-09 18:40 [RFC PATCH 0/2] VFIO no-iommu Alex Williamson
2015-10-09 18:41 ` [RFC PATCH 1/2] vfio: Move vfio.c vfio_core.c Alex Williamson
2015-10-09 19:21   ` Greg KH
2015-10-09 18:41 ` [RFC PATCH 2/2] vfio: Include no-iommu mode Alex Williamson
2015-10-11  8:12   ` Avi Kivity
2015-10-11  8:57     ` Michael S. Tsirkin
2015-10-11  9:03       ` Avi Kivity
2015-10-11  9:19         ` Michael S. Tsirkin
2015-10-11  9:23           ` Gleb Natapov
2015-10-11 21:16     ` Alex Williamson
2015-10-12 15:56   ` Stephen Hemminger [this message]
2015-10-12 16:23     ` Alex Williamson
2015-10-12 16:31       ` Avi Kivity
2015-10-12 16:27     ` Michael S. Tsirkin
2015-10-12 17:46       ` Alex Williamson
2015-10-12 18:08         ` Alex Williamson
2015-10-11 17:29 ` [RFC PATCH 0/2] VFIO no-iommu Varun Sethi
2015-10-11 18:23   ` Alex Williamson
2015-10-11 18:28 ` Michael S. Tsirkin
2015-10-11 18:29   ` Michael S. Tsirkin
2015-10-11 19:25     ` Alex Williamson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151012085607.2c64f98f@urahara \
    --to=stephen@networkplumber.org \
    --cc=alex.williamson@redhat.com \
    --cc=alexander.duyck@gmail.com \
    --cc=avi@cloudius-systems.com \
    --cc=avi@scylladb.com \
    --cc=bruce.richardson@intel.com \
    --cc=corbet@lwn.net \
    --cc=gleb@cloudius-systems.com \
    --cc=gleb@scylladb.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hjk@hansjkoch.de \
    --cc=iommu@lists.linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=vladz@cloudius-systems.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox