From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751538AbbJKJUF (ORCPT ); Sun, 11 Oct 2015 05:20:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33389 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751218AbbJKJUD (ORCPT ); Sun, 11 Oct 2015 05:20:03 -0400 Date: Sun, 11 Oct 2015 12:19:54 +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: <20151011091954.GA27451@redhat.com> References: <20151009182228.14752.99700.stgit@gimli.home> <20151009184110.14752.53531.stgit@gimli.home> <561A19DE.8040302@scylladb.com> <20151011115503-mutt-send-email-mst@redhat.com> <561A25D5.6020906@scylladb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <561A25D5.6020906@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 12:03:17PM +0300, Avi Kivity wrote: > > > On 10/11/2015 11:57 AM, Michael S. Tsirkin wrote: > >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? > > That's just means the capability is there, not that it's active. Well it's currently exactly the same. I guess you can check the return value of VFIO_SET_IOMMU as well. > But since you must pass the same value to open(), you already know that > you're using noiommu. > > >VFIO_IOMMU_MAP_DMA, VFIO_IOMMU_ENABLE and VFIO_IOMMU_DISABLE > >will probably also fail ... > > > > Don't you have to call MAP_DMA to pin the memory? Well check it out - the patch in question doesn't implement this ioctl. In fact it doesn't implement anything except CHECK_EXTENSION. And this makes sense to me: MAP_DMA maps a virtual address to io address, and that doesn't work for the dummy iommu. You can pin memory using many other ways, including mlock and hugetlbfs. -- MST