Message ID | 1535719857-19092-1-git-send-email-alejandro.lucero@netronome.com (mailing list archive) |
---|---|
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3660458FA; Fri, 31 Aug 2018 14:51:55 +0200 (CEST) Received: from netronome.com (host-79-78-33-110.static.as9105.net [79.78.33.110]) by dpdk.org (Postfix) with ESMTP id C7C0358F6; Fri, 31 Aug 2018 14:51:53 +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 w7VCp0Ko019135; Fri, 31 Aug 2018 13:51:00 +0100 Received: (from alucero@localhost) by netronome.com (8.14.4/8.14.4/Submit) id w7VCp0Kh019134; Fri, 31 Aug 2018 13:51:00 +0100 From: Alejandro Lucero <alejandro.lucero@netronome.com> To: dev@dpdk.org Cc: stable@dpdk.org Date: Fri, 31 Aug 2018 13:50:52 +0100 Message-Id: <1535719857-19092-1-git-send-email-alejandro.lucero@netronome.com> X-Mailer: git-send-email 1.9.1 Subject: [dpdk-dev] [PATCH v2 0/5] use IOVAs check based on DMA mask X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
Series |
use IOVAs check based on DMA mask
|
|
Message
Alejandro Lucero
Aug. 31, 2018, 12:50 p.m. UTC
I sent a patchset about this to be applied on 17.11 stable. The memory code has had main changes since that version, so here it is the patchset adjusted to current master repo. This patchset adds, mainly, a check for ensuring IOVAs are within a restricted range due to addressing limitations with some devices. There are two known cases: NFP and IOMMU VT-d emulation. With this check IOVAs out of range are detected and PMDs can abort initialization. For the VT-d case, IOVA VA mode is allowed as long as IOVAs are within the supported range, avoiding to forbid IOVA VA by default. For the addressing limitations known cases, there are just 40(NFP) or 39(VT-d) bits for handling IOVAs. When using IOVA PA, those limitations imply 1TB(NFP) or 512M(VT-d) as upper limits, which is likely enough for most systems. With machines using more memory, the added check will ensure IOVAs within the range. With IOVA VA, and because the way the Linux kernel serves mmap calls in 64 bits systems, 39 or 40 bits are not enough. It is possible to give an address hint with a lower starting address than the default one used by the kernel, and then ensuring the mmap uses that hint or hint plus some offset. With 64 bits systems, the process virtual address space is large enoguh for doing the hugepages mmaping within the supported range when those addressing limitations exist. This patchset also adds a change for using such a hint making the use of IOVA VA a more than likely possibility when there are those addressing limitations. The check is not done by default but just when it is required. This patchset adds the check for NFP initialization and for setting the IOVA mode is an emulated VT-d is detected. Also, because the recent patchset adding dynamic memory allocation, the check is also invoked for ensuring the new memsegs are within the required range. This patchset could be applied to stable 18.05. v2: - fix problem with max dma mask definition
Comments
As I was told, I sent this patchset early September (actually it was still October) for making it for 18.11. I wonder if this will be applied when doing the integration phase or it will need to wait until 19.02. On Fri, Aug 31, 2018 at 1:51 PM Alejandro Lucero < alejandro.lucero@netronome.com> wrote: > I sent a patchset about this to be applied on 17.11 stable. The memory > code has had main changes since that version, so here it is the patchset > adjusted to current master repo. > > This patchset adds, mainly, a check for ensuring IOVAs are within a > restricted range due to addressing limitations with some devices. There > are two known cases: NFP and IOMMU VT-d emulation. > > With this check IOVAs out of range are detected and PMDs can abort > initialization. For the VT-d case, IOVA VA mode is allowed as long as > IOVAs are within the supported range, avoiding to forbid IOVA VA by > default. > > For the addressing limitations known cases, there are just 40(NFP) or > 39(VT-d) bits for handling IOVAs. When using IOVA PA, those limitations > imply 1TB(NFP) or 512M(VT-d) as upper limits, which is likely enough for > most systems. With machines using more memory, the added check will > ensure IOVAs within the range. > > With IOVA VA, and because the way the Linux kernel serves mmap calls > in 64 bits systems, 39 or 40 bits are not enough. It is possible to > give an address hint with a lower starting address than the default one > used by the kernel, and then ensuring the mmap uses that hint or hint plus > some offset. With 64 bits systems, the process virtual address space is > large enoguh for doing the hugepages mmaping within the supported range > when those addressing limitations exist. This patchset also adds a change > for using such a hint making the use of IOVA VA a more than likely > possibility when there are those addressing limitations. > > The check is not done by default but just when it is required. This > patchset adds the check for NFP initialization and for setting the IOVA > mode is an emulated VT-d is detected. Also, because the recent patchset > adding dynamic memory allocation, the check is also invoked for ensuring > the new memsegs are within the required range. > > This patchset could be applied to stable 18.05. > > v2: > - fix problem with max dma mask definition > >
02/10/2018 18:33, Alejandro Lucero: > As I was told, I sent this patchset early September (actually it was still > October) for making it for 18.11. > > I wonder if this will be applied when doing the integration phase or it > will need to wait until 19.02. Such patchset cannot be applied after -rc1. Anatoly, please can you review it to help its integration in 18.11-rc1?