From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f65.google.com (mail-ed1-f65.google.com [209.85.208.65]) by dpdk.org (Postfix) with ESMTP id B3AEC1BDD7 for ; Wed, 27 Jun 2018 12:13:38 +0200 (CEST) Received: by mail-ed1-f65.google.com with SMTP id c1-v6so2750157edt.2 for ; Wed, 27 Jun 2018 03:13:38 -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=OiUTXU/SoO0YO2nDW4DiJEYxfi+NrXPPmYXnEyOKYgc=; b=bFUQ6WB9H6yitdscmP52gF5IRc+tiYA2nUZqpBcorSBnMc+wW3kdkCY4qEhxOp8PoZ 2gtubovhHjdwY6wSD4OakJR92IjJ8Nb+usxqmE5b+cji7vwW3QZNxUVZ/kdp/4q10tMs nzL4ZPXshqi2WQhA2a9MWB1u1D0YAHMK1TeR0ZOYrf2rN5j+WZ6Rhr5NCrBEwfnauzKW 5z5mSWBxyXQm1nUvTHh8aE4ngfQK68LlTNZlceed6p8Vuopnhw2aGCg5Roana8kOZRJ/ NcCG4LbrtnC++B0WN1uauQPP5yEVQWN7v/PE4VhbMUW/gwlVBBqlOECu6V7M0QJpHz6A tpmg== 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=OiUTXU/SoO0YO2nDW4DiJEYxfi+NrXPPmYXnEyOKYgc=; b=S6+1nbDnp4vuMs8mMJqQaTGSaDsFYB+MeslzQpXrVZYh4MNia3Xt+AaxzEHGRWHunQ eTZkvnWBHjqCB0JuQXVQXtjR0w1XWADHvQmwuaKtU/z+LhOCaLZlP4kRwAeIQBcn2gae RgABNSRL8pSD/3P/X6nYZYw3SRKDltPI6XBeDusmU+8ptb/VpbxKhnrS0xakeJj7uUzU DKM4Ln0jMtCxpEpj7gaucOuq6oAII91ortV6hCbaeGTfkxgd5J3cUfVtwJ+ckSIhjmhM c9GGA+XY8vQYDgbfOdgmZMNps+vgBMQkt44ELxxUHwtOJs4/+Wbahppn/fwteFm06L+2 zOfQ== X-Gm-Message-State: APt69E327qYsFFTh9d9x3kU3zgwFPsMV4yZcNtjYj9n2XQCj5xS4nMQw 9EZ9KWJjnPetA685Yxlc8s+kYgBmz/JVVBQd3+URzQ== X-Google-Smtp-Source: AAOMgpe07Le/NwBiAzOtWFcxB7e+hHlKQmLWW9Z2mJlCop/u0qx+B0fjcyfVy5gLsYQqOszhbSrjHLhjY2+JQIKjnFk= X-Received: by 2002:a50:86a1:: with SMTP id r30-v6mr5120328eda.138.1530094418494; Wed, 27 Jun 2018 03:13:38 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a50:b194:0:0:0:0:0 with HTTP; Wed, 27 Jun 2018 03:13:37 -0700 (PDT) In-Reply-To: <552f939e-f28e-0648-1796-8f42269887a2@intel.com> References: <1530034653-28299-1-git-send-email-alejandro.lucero@netronome.com> <552f939e-f28e-0648-1796-8f42269887a2@intel.com> From: Alejandro Lucero Date: Wed, 27 Jun 2018 11:13:37 +0100 Message-ID: To: "Burakov, Anatoly" Cc: dev , stable@dpdk.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [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: Wed, 27 Jun 2018 10:13:38 -0000 On Wed, Jun 27, 2018 at 9:17 AM, Burakov, Anatoly wrote: > 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. > > But memsegs get the iova based on hugepages physaddr, and for VA mode that is based on 0x0 as starting point. And as far as I know, memsegs iovas are what end up being used for IOMMU mappings and what devices will use. > > 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 >