From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) by dpdk.org (Postfix) with ESMTP id A25134D27 for ; Fri, 31 Aug 2018 13:33:27 +0200 (CEST) Received: by mail-ed1-f43.google.com with SMTP id y20-v6so8813791edq.2 for ; Fri, 31 Aug 2018 04:33:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pALKn4tT+DTWS3FguUopB+6BOrxKrJxplNq6kbuWl4Q=; b=n5IXeL60GzdjIiAj7/IldObJ6uCieGhecO4m8mf8DzPJDPxMDcWWsf/dfGcwFqNLSi KxriJFPsLfilUwq1pT/6OZD8Tb15uVpjgfYPHCUSHi25adMN014MOgC7fku2X2QY2ZyK sb4HlgMZ3IRD0LHc1zZAjA06CWzVzFVAVmyHNU3JkWzMMRJ1v+ReSt+bmQ6Ix9St576G 1jWRHseVNVsW+YZf01VNZZxh8DC9xgVqpm8qYtIcEMjS0gspZyzC6OnefCOKpqChmHYv XSZeMhH+MpEo5rHIIOohFUdEBlqBVD3hPNqXFe3iLtb+4kxLSvJa7R6xHmXDrq1qFrZP jBiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pALKn4tT+DTWS3FguUopB+6BOrxKrJxplNq6kbuWl4Q=; b=euAV3Afr5Xg2Z7boa/R6b/zzgqUvdeg2hHEBfBMq+9Aa5yOUR7CaFa3BWP2qkUInAC vIqCrf4k197NhOWqfIfW0EBKwFn1L4YS+jERjl8p0/n3hQ2t9vE8s02WLLnb+WlcLiMg sm2sNI1iSsx9iLvZYaOogGRYRI0OwYF2Xn/1QtT/wKrSACZh+kfyvteUdy2hN4seZ3eS FZrKQBKO4EGPRm1rv8gC1fQ7LeymdFFjW4jk/hVDIzIPZRoManBhSpPs0jHskRL3vBPf nDTUNC7i0zYTZxLzRvFZmdGIszRlELT8rjiyhLgMwSdD/26uNNWpBsfZwf5c8ZV96kT9 b1dw== X-Gm-Message-State: APzg51C+CXIXvsrGzHG8Pk9hM1DJdcZAZf+hYigcM8hx9uhD+1oQBPwG XK4moWN8KKI0zjwmBrrfZL9H11xUVcBYYE0EXjLbgHISXRI= X-Google-Smtp-Source: ANB0VdbzPBmfR4Pqh+i+e4Uf0+8WN6ZgjWJg98WvxeuZ4YGuGvwixOJhseFDdyS0zED86gRRNTOQ0r4GP0DKauwauYQ= X-Received: by 2002:a50:8e09:: with SMTP id 9-v6mr17028741edw.101.1535715207194; Fri, 31 Aug 2018 04:33:27 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:aa7:c64e:0:0:0:0:0 with HTTP; Fri, 31 Aug 2018 04:33:26 -0700 (PDT) In-Reply-To: <1535642492-21831-1-git-send-email-alejandro.lucero@netronome.com> References: <1535642492-21831-1-git-send-email-alejandro.lucero@netronome.com> From: Alejandro Lucero Date: Fri, 31 Aug 2018 13:33:26 +0200 Message-ID: To: dev Cc: dpdk stable Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATH 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2018 11:33:27 -0000 There is a problem with the patch due to a last-hour change regarding MAX_DMA_MASK_BITS. It turns out initial X86_VA_WIDTH definition was to 47 bits, but it is not enough in some systems leading to IOVA VA not available. Because MAX_DMA_MASK_BITS was just used for a sanity check about the mask length, it is harmless to increment the value to 63 for 64-bits systems, but I was really clumsy doing the change and it does not compile now. I've already set the patches as not applicable at patchwork and I will send another version fixing that issue. On Thu, Aug 30, 2018 at 5:21 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. > >