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 BA4708D4D for ; Sat, 12 Dec 2015 00:02:35 +0100 (CET) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id A45F2347A63; Fri, 11 Dec 2015 23:02:34 +0000 (UTC) Received: from t450s.home (ovpn-113-24.phx2.redhat.com [10.3.113.24]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tBBN2XEi022626; Fri, 11 Dec 2015 18:02:34 -0500 Message-ID: <1449874953.20509.6.camel@redhat.com> From: Alex Williamson To: Vincent JARDIN , dev@dpdk.org Date: Fri, 11 Dec 2015 16:02:33 -0700 In-Reply-To: <566B4A50.9090607@6wind.com> References: <60420822.AbcfvjLZCk@xps13> <566B4A50.9090607@6wind.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.23 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: Fri, 11 Dec 2015 23:02:36 -0000 On Fri, 2015-12-11 at 23:12 +0100, Vincent JARDIN wrote: > Thanks Thomas for putting back this topic. > > Alex, > > I'd like to hear more about the impacts of "unsupported": > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commi > t/?id=033291eccbdb1b70ffc02641edae19ac825dc75d >    Use of this mode, specifically binding a device without a native >    IOMMU group to a VFIO bus driver will taint the kernel and should >    therefore not be considered supported. > > It means that we get ride of uio; so it is a nice code cleanup: but > why > would VFIO/NO IOMMU be better if the bottomline is "unsupported"? How supportable do you think the uio method is?  Fundamentally we have a userspace driver doing unrestricted DMA; it can access and modify any memory in the system.  This is the reason uio won't provide a mechanism to enable MSI and if you ask the uio maintainer, they don't support DMA at all, it's only intended as a programmed IO interface to the device.  Unless we can sandbox a user owned device within an IOMMU protected container, it's not supportable.  The VFIO no-iommu mode can simply provide you that unsupported mode more easily since it leverages code from the supported mode, which is IOMMU protected.  Thanks, Alex