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 C3BEBA84C for ; Wed, 17 Jan 2018 09:55:40 +0100 (CET) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1D4067E42F; Wed, 17 Jan 2018 08:55:40 +0000 (UTC) Received: from [10.36.112.32] (ovpn-112-32.ams2.redhat.com [10.36.112.32]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E4FCB63136; Wed, 17 Jan 2018 08:55:38 +0000 (UTC) To: Jonas Pfefferle , Thomas Monjalon Cc: "Burakov, Anatoly" , dev@dpdk.org References: <1509465586-7436-1-git-send-email-jpf@zurich.ibm.com> <2075027.JcYejM7RvO@xps> <30962267.NVMYIIJvp8@xps> From: Maxime Coquelin Message-ID: Date: Wed, 17 Jan 2018 09:55:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Wed, 17 Jan 2018 08:55:40 +0000 (UTC) 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: Wed, 17 Jan 2018 08:55:41 -0000 On 01/17/2018 09:48 AM, Jonas Pfefferle wrote: > >  On Tue, 16 Jan 2018 18:01:32 +0100 >  Maxime Coquelin wrote: >> Hi Jonas, >> >> On 01/16/2018 05:08 PM, Jonas Pfefferle wrote: >>> >>>   On Mon, 15 Jan 2018 17:11:58 +0100 >>>   Thomas Monjalon wrote: >>>> 15/01/2018 13:22, Jonas Pfefferle: >>>>> >>>>>   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? >>>> >>>> Have you looked at what Maxime did? >>>>     https://dpdk.org/dev/patchwork/patch/33650/ >>>> >>>> How does it affect this patch? >>>> >>>> >>> >>> IMO it has the same problem. We shouldn't add more exception cases in >>> drivers/bus/pci/linux/pci.c but instead keep all the information >>> about what an IOMMU can do in lib/librte_eal/linuxapp/eal/eal_vfio.c >> >> I agree adding an exception in drivers/bus/pci/linux/pci.c isn't great, >> but we need first to fix a regression introduced in v17.11 LTS, and >> IMHO, we cannot do a big rework as the fix is to be backported. >> >> Once fixed, I agree we should work on a refactoring. I don't know if >> eal_vfio is the right place though, as in my case for example I cannot >> get the information needed through vfio ioctl(). >> >> Out of curiosity, what prevents sPAPR to use VA mode for now? >> >> Maxime > > Sounds good to me. > > The current sPAPR Linux driver cannot use virtual addresses because the > DMA window size is restricted to RAM size and always starts at 0. This > is not a hardware restriction and we are working on allowing to create > arbitrary size windows. Thanks for the clarification, is the DMA window size information accessible from user-space, so that we can enable VA mode or not depending on its value? Maxime > Jonas > > >