From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by dpdk.org (Postfix) with ESMTP id 3DA612C3F for ; Fri, 3 Nov 2017 12:29:02 +0100 (CET) Received: from pps.filterd (m0098416.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vA3BON8X102555 for ; Fri, 3 Nov 2017 07:29:01 -0400 Received: from smtp.notes.na.collabserv.com (smtp.notes.na.collabserv.com [192.155.248.73]) by mx0b-001b2d01.pphosted.com with ESMTP id 2e0kwech8r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 03 Nov 2017 07:29:01 -0400 Received: from localhost by smtp.notes.na.collabserv.com with smtp.notes.na.collabserv.com ESMTP for from ; Fri, 3 Nov 2017 11:29:00 -0000 Received: from us1a3-smtp06.a3.dal06.isc4sb.com (10.146.103.243) by smtp.notes.na.collabserv.com (10.106.227.90) with smtp.notes.na.collabserv.com ESMTP; Fri, 3 Nov 2017 11:28:53 -0000 Received: from us1a3-mail173.a3.dal06.isc4sb.com ([10.146.71.126]) by us1a3-smtp06.a3.dal06.isc4sb.com with ESMTP id 2017110311285224-366097 ; Fri, 3 Nov 2017 11:28:52 +0000 MIME-Version: 1.0 In-Reply-To: <2435156.eG8feLuSfo@xps> To: Thomas Monjalon Cc: aconole@redhat.com, Alexey Kardashevskiy , anatoly.burakov@intel.com, bruce.richardson@intel.com, dev@dpdk.org, gaetan.rivet@6wind.com, hemant.agrawal@nxp.com, jerin.jacob@caviumnetworks.com, maxime.coquelin@redhat.com, olivier.matz@6wind.com, Santosh Shukla , sergio.gonzalez.monroy@intel.com, shreyansh.jain@nxp.com, stephen@networkplumber.org From: "Jonas Pfefferle1" Date: Fri, 3 Nov 2017 12:28:51 +0100 References: <20170814161059.6684-1-santosh.shukla@caviumnetworks.com> <3063385.K5PMv1yDeD@xps> <2435156.eG8feLuSfo@xps> X-KeepSent: A5F295A0:18EF88B0-C12581CD:003E6973; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0.1 October 14, 2013 X-LLNOutbound: False X-Disclaimed: 48807 X-TNEFEvaluated: 1 x-cbid: 17110311-3107-0000-0000-0000039DC2A9 X-IBM-SpamModules-Scores: BY=0; FL=0; FP=0; FZ=0; HX=0; KW=0; PH=0; SC=0.433748; ST=0; TS=0; UL=0; ISC=; MB=0.302927 X-IBM-SpamModules-Versions: BY=3.00008002; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000239; SDB=6.00940518; UDB=6.00474270; IPR=6.00720774; BA=6.00005669; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00017847; XFM=3.00000015; UTC=2017-11-03 11:28:59 X-IBM-AV-DETECTION: SAVI=unsuspicious REMOTE=unsuspicious XFE=unused X-IBM-AV-VERSION: SAVI=2017-11-03 09:05:36 - 6.00007557 x-cbparentid: 17110311-3108-0000-0000-00006B2ACC0B Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-03_05:, , signatures=0 X-Proofpoint-Spam-Reason: safe Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v7 7/9] linuxapp/eal_vfio: honor iova mode before mapping 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: Fri, 03 Nov 2017 11:29:02 -0000 Thomas Monjalon wrote on 11/03/2017 11:54:45 AM: > From: Thomas Monjalon > To: Jonas Pfefferle1 > Cc: aconole@redhat.com, Alexey Kardashevskiy , > anatoly.burakov@intel.com, bruce.richardson@intel.com, dev@dpdk.org, > gaetan.rivet@6wind.com, hemant.agrawal@nxp.com, > jerin.jacob@caviumnetworks.com, maxime.coquelin@redhat.com, > olivier.matz@6wind.com, Santosh Shukla > , > sergio.gonzalez.monroy@intel.com, shreyansh.jain@nxp.com, > stephen@networkplumber.org > Date: 11/03/2017 11:55 AM > Subject: Re: [dpdk-dev] [PATCH v7 7/9] linuxapp/eal=5Fvfio: honor iova > mode before mapping > > 03/11/2017 11:44, Jonas Pfefferle1: > > Thomas Monjalon wrote on 11/03/2017 11:28:10 AM: > > > 03/11/2017 10:56, Jonas Pfefferle1: > > > > Thomas Monjalon wrote on 11/02/2017 11:17:10 AM: > > > > > > 26/10/2017 14:57, Jonas Pfefferle1: > > > > > > > > > > > > > > Hi @all > > > > > > > > > > > > > > I just stumbled upon this patch while testing on POWER. > > RTE=5FIOVA=5FVA > > > > > will > > > > > > > not work for the sPAPR code since the dma window size is > > currently > > > > > > > determined by the physical address only. > > > > > > > > > > > > Is it affecting POWER8? > > > > > > > > > > It is. > > > > > > > > > > > > > > > > > > I'm preparing a patch to address this. > > > > > > > > > > > > Any news? > > > > > > Can you use virtual addresses? > > > > > > > > > > After a long discussion with Alexey (CC) we came to the conclusion > > that > > > > > with the current sPAPR iommu driver we cannot use virtual addresses > > since > > > > > the iova is restricted to lay in the DMA window which itself is > > > > restricted > > > > > to physical RAM addresses resp. with the current code 0 to hotplug > > memory > > > > > max. However, Alexey is working on a patch to lift this restriction > > on > > > > the > > > > > DMA window size which should allow us to do VA:VA mappings in the > > future. > > > > > For now we should fall back to PA in the dynamic iova mode check. I > > will > > > > > send an according patch later today. > > > > > > > > I looked into this yesterday but I'm not sure what the right solution > > is > > > > here. > > > > At the time rte=5Fpci=5Fget=5Fiommu=5Fclass is called we already kn= ow which > > IOMMU > > > > types are supported because vfio=5Fget=5Fcontainer=5Ffd resp. > > > > vfio=5Fhas=5Fsupported=5Fextensions has been called however we do = not know > > which > > > > one is going to be used (Decided later in vfio=5Fsetup=5Fdevice res= p. > > > > vfio=5Fset=5Fiommu=5Ftype). We can choose a iova mode which is supp= orted by > > all > > > > types but if the modes are exclusive to the types we have to guess > > which > > > > one is going to be used. Or let the user decide? > > > > > > You can keep the old behaviour, restricting to physical memory, > > > until you support virtual addressing. > > > It can be just a #ifdef RTE=5FARCH=5FPPC=5F64. > > > > > > > Ok but we might want to refine this in the future. IMO It looks much > > cleaner > > to decide this on the iommu type plus this would also cover the noiommu > > case without having this extra check reading the sysfs variable. > > You are using the word "this" too many times to help me understand :) What I meant is a fix that decides which iova mode to use based on the iommu types supported (determined by vfio=5Fget=5Fcontainer=5Ffd) instead of another extra case for PPC much like the noiommu check. Both should be covered by the supported types based check. IMO much cleaner and simpler to support new iommu types. > > Anyway, please send a quick fix today for 17.11. > The RC3 will be probably closed before Monday. > Will do.