From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Williamson Subject: Re: VFIO no-iommu Date: Wed, 13 Jan 2016 23:52:29 -0700 Message-ID: <1452754349.14628.10.camel@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" To: Jike Song 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) In-Reply-To: List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, 2016-01-14 at 14:03 +0800, Jike Song wrote: > On Wed, Dec 16, 2015 at 12:38 PM, Alex Williamson > wrote: > >=20 > > So it works.=C2=A0=C2=A0Is it acceptable?=C2=A0=C2=A0Useful?=C2=A0=C2= =A0Sufficiently complete?=C2=A0=C2=A0Does > > it imply deprecating the uio interface?=C2=A0=C2=A0I believe the feat= ure 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).=C2=A0=C2=A0Implementing that would be the ultimat= e test of > > whether this provides dpdk with not only a more consistent interface, > > but the feature dpdk wants that's missing in uio. Thanks, > >=20 > Hi Alex, >=20 > Sorry for jumping in.=C2=A0=C2=A0Just being curious, how does VFIO No-I= OMMU mode > support DMA from userspace drivers?=C2=A0=C2=A0If I understand correctl= y, 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. =C2=A0vfio no-iommu is meant t= o 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. =C2=A0This is why vfio no- iommu taints the kernel. =C2=A0With that in mind, one of the design goals= is to introduce as little code as possible for vfio no-iommu. =C2=A0A new vf= io iommu backend with pinning and virt-to-bus translation goes against that design goal. =C2=A0I don't know the details of how DPDK did this wit= h UIO, but the same lack of DMA mapping facilities is present with vfio no-iommu. =C2=A0It really just brings the vfio device model, nothing more= . Thanks, Alex