From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ferruh Yigit Subject: Re: [PATCH v1] igu_uio: fix IOMMU domain issue Date: Wed, 11 May 2016 18:24:38 +0100 Message-ID: <57336AD6.1050809@intel.com> References: <1462879301-13570-1-git-send-email-zhe.tao@intel.com> <20160510085915.529b4af5@xeon-e3> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Zhe Tao , dev To: Alejandro Lucero , Stephen Hemminger Return-path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id A4961677E for ; Wed, 11 May 2016 19:24:41 +0200 (CEST) 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 5/11/2016 8:35 AM, Alejandro Lucero wrote: > On Tue, May 10, 2016 at 4:59 PM, Stephen Hemminger < > stephen@networkplumber.org> wrote: >=20 >> On Tue, 10 May 2016 19:21:41 +0800 >> Zhe Tao wrote: >> >>> Problem: >>> The following operations will cause the igb_uio based DPDK >>> operation failed. >>> --Any device assignment through the kvm_assign_device interface, >>> this can be the pci-assign method in QEMU >>> --VFIO group attachment operation(attach to the container) >>> this can happens in vfio-pci assignment in QEMU >> >> >> If you have an IOMMU why not use VFIO instead, it is better. >> >=20 > It is not about VFIO against UIO but about how iommu domains are create= d > and destroyed by the (old) kernel when iommu=3Dpt. So even with VFIO yo= u can > have problems. Problem is in IOMMU driver but we are adding a workaround to igb_uio, if using VFIO solves the issue, I believe that is better workaround. 1) Is there any case IOMMU supported but VFIO is not supported? Is there anything forces to use igb_uio? 2) Does using VFIO solves the issue defined in problem statement? >=20 > We have had problems like this and other due to our device (NFP) just > mapping up to 40 bits of address space. Old kernels used in LTS > distributions like Ubuntu are iommu buggy and you need to do things lik= e > this mapping inside the driver for solving problems. By the way, using > SRIOV just adds more problems. It is not safe to use iommu=3Dpt with 3.= 13.x > Ubuntu kernels. >=20 > It would be a good thing for the original patch to identify those kerne= ls > where the problem was detected. Of course, there could be more kernels = with > the same problem but that is more work to do. >=20 Thanks, ferruh