From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com [209.85.213.178]) by dpdk.org (Postfix) with ESMTP id A353F8E84 for ; Thu, 14 Jan 2016 09:12:45 +0100 (CET) Received: by mail-ig0-f178.google.com with SMTP id z14so187206336igp.0 for ; Thu, 14 Jan 2016 00:12:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=StbiQaNyijYwfnWUYwe2sIJgSlsKHFhLOjI6GzDFYIg=; b=lfIA4fTgfIJK7NmAIvoEezxzHNkG3sNWacreLhAB/jfRhsN0/eUhh5fJxbH9lZRzMK vNzxY12kAhUCcNw1pSw6Yo8uVRLDb+6lbJMr3/9SCSeG3RskK4wZwa1PUl5IQmMicW0Z /j7Vwri0Waalm1Mt68a0GPw7Al/94Err7rPGIt8hGj6Gr8ueXbp+/EZHM93NYJH769oY OOQVr+ZeDuzVQP2dzfXwC0mPIorQl/MCKXyQKlu8yhFa6U4IIJKYlYWjOK+8+x0PDQOS 2Bl46cKyN3C02tfaAf60Y6pW0QEEBgU//n6WHaURJiduR/5CwAtgZXe+QvfjyREVAshw TzfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=StbiQaNyijYwfnWUYwe2sIJgSlsKHFhLOjI6GzDFYIg=; b=aiZw+CU6fwpIHOkhlEwaIJliery9xWagWJOE9YS9lYWwQmY11Rf72f9+Qgabmxu0Y7 3lYKAatmDSjiBeXxDZw/yooQBHlSO6ALEzhhSNKG4OyUfpzJ/YKkLRxfPc06QKgzSYi/ AyFd45pNllfBmJtZyiGkGVx606FA0BIwUpioqrUXm+aEAr8Ai79EDlSWFOrYDt95G0Lb RJxZ3M7dkrGW96ERXTug05l444RfEYGQeVWVhYr7gGKawasqr6VI6a+1A9OUlxudcwK+ plcewGKEuhb2wQHnrWRWaRKufU7mMmqkOWhaqy0YC4lmnWwRYF9WuF3eDNCjley48+Ye wJYQ== X-Gm-Message-State: ALoCoQnmWhPl5BuyIiRkA/HJzsIGkqo7t29PCNTvBJJTxvNYvUVrgDyxo9xnXQizCX/atDuJqxIptYLQAXfiwj70XXDEWNCXhA== MIME-Version: 1.0 X-Received: by 10.50.143.103 with SMTP id sd7mr5418106igb.60.1452759165161; Thu, 14 Jan 2016 00:12:45 -0800 (PST) Received: by 10.64.102.229 with HTTP; Thu, 14 Jan 2016 00:12:45 -0800 (PST) In-Reply-To: <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> <1452754349.14628.10.camel@redhat.com> Date: Thu, 14 Jan 2016 16:12:45 +0800 Message-ID: From: Jike Song To: Alex Williamson Content-Type: text/plain; charset=UTF-8 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 08:12:46 -0000 On Thu, Jan 14, 2016 at 2:52 PM, Alex Williamson wrote: > 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 Thanks! - that addressed my question :) By the way, my previous assumption(consulting /proc//pagemap) apparently doesn't work: one cannot assume a usespace buffer is physically continuous. -- Thanks, Jike