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 7A31CA04AE; Wed, 6 Nov 2019 23:12:08 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1B6BB1C2BF; Wed, 6 Nov 2019 23:12:08 +0100 (CET) Received: from wnew4-smtp.messagingengine.com (wnew4-smtp.messagingengine.com [64.147.123.18]) by dpdk.org (Postfix) with ESMTP id 1EB0C1C219 for ; Wed, 6 Nov 2019 23:12:07 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.west.internal (Postfix) with ESMTP id 234C9475; Wed, 6 Nov 2019 17:12:05 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 06 Nov 2019 17:12:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=Ehdj2Zd4LtrCOGM5pXQZMPfHIslDf+iFFdYNd4gfZcU=; b=a0osnHfbbaUs AJDiNPV23WUWVRDOfMtADMh8pq0gkeBw6lJvpBMGSBShIIIuS7iio5a6tFAgAUnp SnMpL6gBqLz5dYYQoI67YbnPcFFJxsr79KDMygcBtyU/KxfftgUvWXuzhZO7th0w xNNzQbe88kvwireEhCD7osvM7ZpS9uM= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=Ehdj2Zd4LtrCOGM5pXQZMPfHIslDf+iFFdYNd4gfZ cU=; b=TG8FRdE6hBHbUbluaMVuLiKwows7nWSgtPr6Z+gbAFIJyKcJOPRUxFQ4W 14S/YhFUEI0ILbQjPSojaiaKEElchEDexGthHLdsW+q8OrxLUd5LgLo7eldFFP6x wUkwQ3HRTBkiEJHpdlSY6maK4E7mTx6xfDemB7tjxR0zCEyqjt19bpmMb0nckspt l8xqL+syyt9khV10WFK00HmoYXL8oNFfwEg7xL4cpiEeyI5EgLdZzsIt0e4tzD9c 6w6H5vpfYZQzxdkYwHQ20L5cISQn0Yk0lAhWr62eWs9bpXWjzDpGtj4pW1Md5U6z FQHidz7+ifX+5qIa8KaKGDFJ39MrQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddujedgudeitdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc fkphepjeejrddufeegrddvtdefrddukeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpeht hhhomhgrshesmhhonhhjrghlohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 1A40E8005C; Wed, 6 Nov 2019 17:12:02 -0500 (EST) From: Thomas Monjalon To: David Marchand , Anatoly Burakov Cc: dev , Bruce Richardson , Rajesh Ravi , Ajit Khaparde , Jonathan Richardson , Scott Branden , Vikram Mysore Prakash , Srinath Mannam , Kevin Traynor Date: Wed, 06 Nov 2019 23:12:00 +0100 Message-ID: <12687014.fTV4V1tnDX@xps> In-Reply-To: References: <5dd669557fc499df5e345a14c9252c095eff6c07.1572966906.git.anatoly.burakov@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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" 06/11/2019 22:53, David Marchand: > On Tue, Nov 5, 2019 at 4: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. > > I'd say we still have to Cc: stable, on the principle so that the > stable maintainers know there is an issue on this commit. Yes I agree. Cc: stable should be in this commit log. Adding Cc: stable does not mean the patch can be backported without any effort :)