From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752462AbbJKVQy (ORCPT ); Sun, 11 Oct 2015 17:16:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33741 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751409AbbJKVQx (ORCPT ); Sun, 11 Oct 2015 17:16:53 -0400 Message-ID: <1444598211.4059.291.camel@redhat.com> Subject: Re: [RFC PATCH 2/2] vfio: Include no-iommu mode From: Alex Williamson To: Avi Kivity Cc: 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: Sun, 11 Oct 2015 15:16:51 -0600 In-Reply-To: <561A19DE.8040302@scylladb.com> References: <20151009182228.14752.99700.stgit@gimli.home> <20151009184110.14752.53531.stgit@gimli.home> <561A19DE.8040302@scylladb.com> 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 Sun, 2015-10-11 at 11:12 +0300, Avi Kivity wrote: > > On 10/09/2015 09:41 PM, Alex Williamson 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. > > CAP_SYS_RAWIO seems a better match (in particular, it allows access to > /dev/mem, which is the same thing). Sure, that seems reasonable. > > 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. > > I did not see an API for detecting whether memory translation is > provided or not. We can have the caller guess this by looking at the > device name, or by requiring the user to specify this, but I think it's > cleaner to provide programmatic access to this attribute. The VFIO user can probe and needs to set the IOMMU model in use before they can access a device file descriptor. In this mode, the VFIO_NOIOMMU_IOMMU is the only model available, which as proposed here provides no translation, and in fact no mapping ioctls. Thanks, Alex