From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from netronome.com (host-79-78-33-110.static.as9105.net [79.78.33.110]) by dpdk.org (Postfix) with ESMTP id 7DF911BE3D; Tue, 26 Jun 2018 19:38:04 +0200 (CEST) Received: from netronome.com (localhost [127.0.0.1]) by netronome.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w5QHbbxi028346; Tue, 26 Jun 2018 18:37:37 +0100 Received: (from alucero@localhost) by netronome.com (8.14.4/8.14.4/Submit) id w5QHbZvH028345; Tue, 26 Jun 2018 18:37:35 +0100 From: Alejandro Lucero To: dev@dpdk.org Cc: stable@dpdk.org, anatoly.burakov@intel.com Date: Tue, 26 Jun 2018 18:37:27 +0100 Message-Id: <1530034653-28299-1-git-send-email-alejandro.lucero@netronome.com> X-Mailer: git-send-email 1.9.1 Subject: [dpdk-stable] [RFC] Add support for device dma mask X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 17:38:05 -0000 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. 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.