From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 9A1B6A04AB; Wed, 6 Nov 2019 14:58:52 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D9C0D1C1BF; Wed, 6 Nov 2019 14:58:51 +0100 (CET) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by dpdk.org (Postfix) with ESMTP id 7C7DD1C139 for ; Wed, 6 Nov 2019 14:58:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1573048728; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=YEhXMGvFTN5RffnLL+3y2Sz02urNksR7puetrVeBtJA=; b=SXo2msYu+HZ6tFm9oXxK6uOZQ4uqpkMeX06EGruBimjquNw3c1w/3YxSNVLvrIdcwJPbVT cF98K+fieMUrc6iMsUooKduIrW68RcYPoEz881cBTpG555OaLchkE1e4ZZ2T8uBnz/kwPP lSv9RjZ0aE8fGKdaPZDZAFkYknyrKPA= Received: from mail-vk1-f200.google.com (mail-vk1-f200.google.com [209.85.221.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-78-tPoDrupNPGKf2DFsKlrSWQ-1; Wed, 06 Nov 2019 08:58:47 -0500 Received: by mail-vk1-f200.google.com with SMTP id z23so10767643vkb.3 for ; Wed, 06 Nov 2019 05:58:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hvrcuCDaN8v8joXvHVavseoIDQ1bz8IRHe8HrHUw+2g=; b=VJNTyUPMx1PQQvgOiriG4zWatMXoMkeOve5Ueo4c47OrGm38hSDDgFf9x4Z8ogRwhE ZTwtN5ncRkpGfXeR0QjMKLpxirl9YLIz8e95lrcBbH8ws0S14BvQ5gGTLYAd55ic85CY BE0NdFspAnc2f6X2fgmPNchQKK7tmLy5+dEK5Hin5u/5gmjb6f7uaGFCX1xGZq7m7Xxa 19wBxVdTZjvQDMGEqRR4Z3KWqMlGaPC6p7u3zMiFcqNjJQ3as2aWsr2MUNG0fbaXGdIn Ce7FagatVa9gkI29b5jiawmV0EAVoX9DboLJMGDH7g1XzetVU1IwfhCXXmupqi+0WM1p EOSg== X-Gm-Message-State: APjAAAUDNJSUlcYPOEm9zi7YP9u5PQ9L+qW05fZA68c4HqIrlS/rahqC zKEr0KiuyTZnJwUkN145Gn3n2Hps7pn5aty0fHixBJXx0+lbqMc9aqU87kYosrE8w5JjpfH89t0 uB4A4LnILKwCcf+1njGs= X-Received: by 2002:a67:bd05:: with SMTP id y5mr1358792vsq.180.1573048726710; Wed, 06 Nov 2019 05:58:46 -0800 (PST) X-Google-Smtp-Source: APXvYqykuNNpuG3Rlykm76fhpDr9gx/DABTuB/BrqmO0+uAUuSYUmaUDGFcaBv1xAjAvOPQsa4VpGxrpRERdUwiTCdY= X-Received: by 2002:a67:bd05:: with SMTP id y5mr1358766vsq.180.1573048726358; Wed, 06 Nov 2019 05:58:46 -0800 (PST) MIME-Version: 1.0 References: <5dd669557fc499df5e345a14c9252c095eff6c07.1572966906.git.anatoly.burakov@intel.com> In-Reply-To: From: David Marchand Date: Wed, 6 Nov 2019 14:58:35 +0100 Message-ID: To: "Burakov, Anatoly" Cc: dev , Bruce Richardson , Rajesh Ravi , Ajit Khaparde , Jonathan Richardson , Scott Branden , Vikram Mysore Prakash , Srinath Mannam , Thomas Monjalon X-MC-Unique: tPoDrupNPGKf2DFsKlrSWQ-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH 19.11] vfio: fix DMA mapping of externally allocated heaps 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Tue, Nov 5, 2019 at 6:15 PM Burakov, Anatoly wrote: > > On 05-Nov-19 3:15 PM, Anatoly Burakov wrote: > > Currently, externally created heaps are supposed to be automatically > > mapped for VFIO DMA by EAL, however they only do so if, at the time of > > heap creation, VFIO is initialized and has at least one device > > available. If no devices are available at the time of heap creation (or > > if devices were available, but were since hot-unplugged, thus dropping > > all VFIO container mappings), then VFIO mapping code would have skipped > > over externally allocated heaps. > > > > The fix is two-fold. First, we allow externally allocated memory > > segments to be marked as "heap" segments. This allows us to distinguish > > between external memory segments that were created via heap API, from > > those that were created via rte_extmem_register() API. > > > > Then, we fix the VFIO code to only skip non-heap external segments. > > Also, since external heaps are not guaranteed to have valid IOVA > > addresses, we will skip those which have invalid IOVA addresses as well= . > > > > Fixes: 0f526d674f8e ("malloc: separate creating memseg list and malloc = heap") > > > > Signed-off-by: Anatoly Burakov > > --- > > > > Notes: > > This cannot be backported to older releases as it breaks the > > API and ABI. A separate fix is in the works for stable. > > > > Alternative, non-breaking implementation available (which will be slower > due to O(N) memseg list heaps lookups): > > http://patches.dpdk.org/patch/62486/ > > I'm fine with either option being merged. > > The more perfect solution would've been to rename "msl->external" into > "msl->flags" and have various flags for memseg lists, but it's too late > to break the API now. Either way is fine for me (between the 18.11 and the master patches you sen= t). Breaking the ABI is acceptable, but I agree the API is another story. If the code seems better to you with the additional heap flag, let's go for= it. I would still like to hear from Rajesh though, since he seems to be the first to hit this issue. --=20 David Marchand