From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id C985F1BE3F; Wed, 27 Jun 2018 10:18:02 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jun 2018 01:18:01 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,278,1526367600"; d="scan'208";a="61759256" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.252.30.203]) ([10.252.30.203]) by fmsmga002.fm.intel.com with ESMTP; 27 Jun 2018 01:17:59 -0700 To: Alejandro Lucero , dev@dpdk.org Cc: stable@dpdk.org References: <1530034653-28299-1-git-send-email-alejandro.lucero@netronome.com> From: "Burakov, Anatoly" Message-ID: <552f939e-f28e-0648-1796-8f42269887a2@intel.com> Date: Wed, 27 Jun 2018 09:17:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <1530034653-28299-1-git-send-email-alejandro.lucero@netronome.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [RFC] Add support for device dma mask 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, 27 Jun 2018 08:18:04 -0000 On 26-Jun-18 6:37 PM, Alejandro Lucero wrote: > This RFC tries to handle devices with addressing limitations. NFP devices > 4000/6000 can just handle addresses with 40 bits implying problems for handling > physical address when machines have more than 1TB of memory. But because how > iovas are configured, which can be equivalent to physical addresses or based on > virtual addresses, this can be a more likely problem. > > I tried to solve this some time ago: > > https://www.mail-archive.com/dev@dpdk.org/msg45214.html > > It was delayed because there was some changes in progress with EAL device > handling, and, being honest, I completely forgot about this until now, when > I have had to work on supporting NFP devices with DPDK and non-root users. > > I was working on a patch for being applied on main DPDK branch upstream, but > because changes to memory initialization during the last months, this can not > be backported to stable versions, at least the part where the hugepages iovas > are checked. > > I realize stable versions only allow bug fixing, and this patchset could > arguably not be considered as so. But without this, it could be, although > unlikely, a DPDK used in a machine with more than 1TB, and then NFP using > the wrong DMA host addresses. > > Although virtual addresses used as iovas are more dangerous, for DPDK versions > before 18.05 this is not worse than with physical addresses, because iovas, > when physical addresses are not available, are based on a starting address set > to 0x0. You might want to look at the following patch: http://patches.dpdk.org/patch/37149/ Since this patch, IOVA as VA mode uses VA addresses, and that has been backported to earlier releases. I don't think there's any case where we used zero-based addresses any more. Since 18.05, those iovas can, and usually are, higher than 1TB, as they > are based on 64 bits address space addresses, and by default the kernel uses a > starting point far higher than 1TB. > > This patchset applies to stable 17.11.3 but I will be happy to submit patches, if > required, for other DPDK stable versions. > > -- Thanks, Anatoly