From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 121408E74 for ; Thu, 14 Jan 2016 07:52:32 +0100 (CET) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 48B978CF5D; Thu, 14 Jan 2016 06:52:31 +0000 (UTC) Received: from t450s.home ([10.3.113.18]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0E6qUOB016256; Thu, 14 Jan 2016 01:52:30 -0500 Message-ID: <1452754349.14628.10.camel@redhat.com> From: Alex Williamson To: Jike Song Date: Wed, 13 Jan 2016 23:52:29 -0700 In-Reply-To: References: <60420822.AbcfvjLZCk@xps13> <566B4A50.9090607@6wind.com> <1449874953.20509.6.camel@redhat.com> <26FA93C7ED1EAA44AB77D62FBE1D27BA6747CE55@IRSMSX108.ger.corp.intel.com> <1450198398.6042.32.camel@redhat.com> <20151216040408.GA18363@sivlogin002.ir.intel.com> <1450240711.2674.11.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] VFIO no-iommu X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 06:52:32 -0000 On Thu, 2016-01-14 at 14:03 +0800, Jike Song wrote: > On Wed, Dec 16, 2015 at 12:38 PM, Alex Williamson > wrote: > > > > So it works.  Is it acceptable?  Useful?  Sufficiently complete?  Does > > it imply deprecating the uio interface?  I believe the feature that > > started this discussion was support for MSI/X interrupts so that VFs > > can support some kind of interrupt (uio only supports INTx since it > > doesn't allow DMA).  Implementing that would be the ultimate test of > > whether this provides dpdk with not only a more consistent interface, > > but the feature dpdk wants that's missing in uio. Thanks, > > > Hi Alex, > > Sorry for jumping in.  Just being curious, how does VFIO No-IOMMU mode > support DMA from userspace drivers?  If I understand correctly, due to > the absence of IOMMU, pcidev has to use physaddr to start a DMA > transaction, but how it is supposed to get physaddr from userspace > drivers, /proc//pagemap or something else? Hi Jike, vfio no-iommu does nothing to facilitate DMA mappings, UIO didn't either and DPDK managed to work with that.  vfio no-iommu is meant to be an enabler and provide a consistent vfio device model (with MSI/X interrupts), but fundamentally the idea of a non-iommu protected, user owned device capable of DMA is unsupportable.  This is why vfio no- iommu taints the kernel.  With that in mind, one of the design goals is to introduce as little code as possible for vfio no-iommu.  A new vfio iommu backend with pinning and virt-to-bus translation goes against that design goal.  I don't know the details of how DPDK did this with UIO, but the same lack of DMA mapping facilities is present with vfio no-iommu.  It really just brings the vfio device model, nothing more. Thanks, Alex