From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BC4FFC5DF60 for ; Tue, 5 Nov 2019 17:15:19 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id 79CA220663 for ; Tue, 5 Nov 2019 17:15:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 79CA220663 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D74AA1BEFD; Tue, 5 Nov 2019 18:15:18 +0100 (CET) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id A2E181BEFB for ; Tue, 5 Nov 2019 18:15:17 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Nov 2019 09:15:16 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,271,1569308400"; d="scan'208";a="225176462" Received: from aburakov-mobl1.ger.corp.intel.com (HELO [10.237.220.92]) ([10.237.220.92]) by FMSMGA003.fm.intel.com with ESMTP; 05 Nov 2019 09:15:14 -0800 To: dev@dpdk.org Cc: Bruce Richardson , rajesh.ravi@broadcom.com, ajit.khaparde@broadcom.com, jonathan.richardson@broadcom.com, scott.branden@broadcom.com, vikram.prakash@broadcom.com, srinath.mannam@broadcom.com, david.marchand@redhat.com, thomas@monjalon.net References: <5dd669557fc499df5e345a14c9252c095eff6c07.1572966906.git.anatoly.burakov@intel.com> From: "Burakov, Anatoly" Message-ID: Date: Tue, 5 Nov 2019 17:15:13 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <5dd669557fc499df5e345a14c9252c095eff6c07.1572966906.git.anatoly.burakov@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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 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. -- Thanks, Anatoly