From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) by dpdk.org (Postfix) with ESMTP id 7F0242BB5 for ; Mon, 15 Jan 2018 13:22:29 +0100 (CET) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 53131340881; Mon, 15 Jan 2018 13:22:29 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.16926); Mon, 15 Jan 2018 13:22:24 +0100 (CET) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Mon, 15 Jan 2018 13:22:24 +0100 (CET) Received: from [195.176.20.45] (account pepperjo@japf.ch) by japf.ch (CommuniGate Pro WEBUSER 6.1.18) with HTTP id 42154784; Mon, 15 Jan 2018 13:22:24 +0100 From: "Jonas Pfefferle" To: "Thomas Monjalon" , "Burakov, Anatoly" Cc: dev@dpdk.org X-Mailer: CommuniGate Pro WebUser v6.1.18 Date: Mon, 15 Jan 2018 13:22:24 +0100 Message-ID: In-Reply-To: <2075027.JcYejM7RvO@xps> References: <1509465586-7436-1-git-send-email-jpf@zurich.ibm.com> <5559040.Nhk1psZjz2@xps> <45d1aa7c-2ceb-b6df-8e16-83ff1316cba1@intel.com> <2075027.JcYejM7RvO@xps> MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8; format="flowed" Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v2] vfio: noiommu check error handling X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2018 12:22:29 -0000 On Sat, 13 Jan 2018 23:49:30 +0100 Thomas Monjalon wrote: > 13/01/2018 13:15, Burakov, Anatoly: >> On 11-Jan-18 11:45 PM, Thomas Monjalon wrote: >> > 07/11/2017 10:50, Jonas Pfefferle1: >> >>> Is there something urgent for 17.11? >> >>> Or can it be refined in 18.02? >> >> >> >> Nothing urgent. We can refine this for 18.02. >> >> >> >>> Anatoly, any thought? >> > >> > Anatoly, Jonas, how do you want to proceed with this patch? >> > >> >> I don't see anything to be refined here, it's a simple bug fix - >>code >> assumes noiommu mode support is always available, when it might not >>be >> the case on older kernels. > > As a bug fix, the title must start with "fix" and a tag "Fixes:" > must be added to help with backport. > At the same time, the explanation of the bug must be added in > the commit log please. > > Thanks It's not really a bug fix since it does not change the semantic of the function but just adds nicer error handling. Regarding redefining the code: What I don't like is the special cases we have to check for when using the sPAPR iommu because it does not support VA mappings yet. I think we should decide which iova mode to use based on the iommu types available, i.e. each iommu type should report which iova type it supports. Thoughts? Jonas (new email address)