From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <anatoly.burakov@intel.com>
Received: from mga11.intel.com (mga11.intel.com [192.55.52.93])
 by dpdk.org (Postfix) with ESMTP id 9D7F21CB45
 for <dev@dpdk.org>; Thu,  5 Apr 2018 13:30:53 +0200 (CEST)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga005.jf.intel.com ([10.7.209.41])
 by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
 05 Apr 2018 04:30:52 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.48,411,1517904000"; d="scan'208";a="214145924"
Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.237.220.128])
 ([10.237.220.128])
 by orsmga005.jf.intel.com with ESMTP; 05 Apr 2018 04:30:48 -0700
To: dev@dpdk.org
Cc: Bruce Richardson <bruce.richardson@intel.com>, keith.wiles@intel.com,
 jianfeng.tan@intel.com, andras.kovacs@ericsson.com,
 laszlo.vadkeri@ericsson.com, benjamin.walker@intel.com, thomas@monjalon.net,
 konstantin.ananyev@intel.com, kuralamudhan.ramakrishnan@intel.com,
 louise.m.daly@intel.com, nelio.laranjeiro@6wind.com, yskoh@mellanox.com,
 pepperjo@japf.ch, jerin.jacob@caviumnetworks.com, hemant.agrawal@nxp.com,
 olivier.matz@6wind.com, shreyansh.jain@nxp.com,
 gowrishankar.m@linux.vnet.ibm.com,
 Pawel Wodkowski <pawelx.wodkowski@intel.com>
References: <cover.1520428025.git.anatoly.burakov@intel.com>
 <cover.1522797505.git.anatoly.burakov@intel.com>
 <0de49c396f7e2c0651acb4cc4a575919234f4c8d.1522797505.git.anatoly.burakov@intel.com>
From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Message-ID: <21db37b3-c9ea-7994-a2f7-639f69f2ab32@intel.com>
Date: Thu, 5 Apr 2018 12:30:47 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <0de49c396f7e2c0651acb4cc4a575919234f4c8d.1522797505.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 v3 46/68] vfio: allow to map other memory
 regions
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://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Apr 2018 11:30:54 -0000

On 04-Apr-18 12:21 AM, Anatoly Burakov wrote:
> Currently it is not possible to use memory that is not owned by DPDK to
> perform DMA. This scenarion might be used in vhost applications (like
> SPDK) where guest send its own memory table. To fill this gap provide
> API to allow registering arbitrary address in VFIO container.
> 
> Signed-off-by: Pawel Wodkowski <pawelx.wodkowski@intel.com>
> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
> Signed-off-by: Gowrishankar Muthukrishnan <gowrishankar.m@linux.vnet.ibm.com>
> ---

@Gowrishankar,

We've discussed this privately already, but just to make sure it is 
publicly stated: as it is, parts of this patchset for PPC64 have 
potential issues with them.

Unmapping and remapping the entire segment list on alloc introduces a 
race condition - what if a DMA request comes in while we're in the 
middle of remapping? We cannot realistically stop NICs from doing DMA 
while some other thread is allocating memory.

There is also a larger issue that i've raised in a previous response to 
this patch [1], and PPC64 will will have this problem worse, because not 
only  the described issue will happen on hot-unplug/hotplug, but it may 
also happen during regular allocations, because PPC64 IOMMU will drop 
all mappings on window resize.

[1] http://dpdk.org/ml/archives/dev/2018-April/095182.html

-- 
Thanks,
Anatoly