From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751398AbbJKI6L (ORCPT ); Sun, 11 Oct 2015 04:58:11 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57658 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751102AbbJKI6J (ORCPT ); Sun, 11 Oct 2015 04:58:09 -0400 Date: Sun, 11 Oct 2015 11:57:59 +0300 From: "Michael S. Tsirkin" To: Avi Kivity Cc: Alex Williamson , avi@cloudius-systems.com, gleb@scylladb.com, corbet@lwn.net, bruce.richardson@intel.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 Subject: Re: [RFC PATCH 2/2] vfio: Include no-iommu mode Message-ID: <20151011115503-mutt-send-email-mst@redhat.com> References: <20151009182228.14752.99700.stgit@gimli.home> <20151009184110.14752.53531.stgit@gimli.home> <561A19DE.8040302@scylladb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <561A19DE.8040302@scylladb.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Oct 11, 2015 at 11:12:14AM +0300, Avi Kivity wrote: > > 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. It seems that caller can just check for VFIO_NOIOMMU_IOMMU. Isn't this why it's there? VFIO_IOMMU_MAP_DMA, VFIO_IOMMU_ENABLE and VFIO_IOMMU_DISABLE will probably also fail ... -- MST