From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753172AbbKPRHB (ORCPT ); Mon, 16 Nov 2015 12:07:01 -0500 Received: from mx1.redhat.com ([209.132.183.28]:29047 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751343AbbKPRG5 (ORCPT ); Mon, 16 Nov 2015 12:06:57 -0500 Message-ID: <1447693613.3946.258.camel@redhat.com> Subject: Re: [PATCH] vfio: Include No-IOMMU mode From: Alex Williamson To: "alex.williamson" 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, stephen@networkplumber.org, vladz@cloudius-systems.com, iommu@lists.linux-foundation.org, hjk@hansjkoch.de, gregkh@linuxfoundation.org Date: Mon, 16 Nov 2015 10:06:53 -0700 In-Reply-To: <20151028211309.14155.23867.stgit@gimli.home> References: <20151028211309.14155.23867.stgit@gimli.home> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.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 > --- > > 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