From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 8A9A1A00E6 for ; Wed, 12 Jun 2019 16:06:19 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 6764E1C610; Wed, 12 Jun 2019 16:06:18 +0200 (CEST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 4FD6B1C3DD for ; Wed, 12 Jun 2019 16:06:17 +0200 (CEST) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A869430C0DDC; Wed, 12 Jun 2019 14:06:01 +0000 (UTC) Received: from dhcp-25.97.bos.redhat.com (unknown [10.18.25.61]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 523B26A250; Wed, 12 Jun 2019 14:06:01 +0000 (UTC) From: Aaron Conole To: Takeshi Yoshimura Cc: dev@dpdk.org References: <20190612063313.2729-1-tyos@jp.ibm.com> Date: Wed, 12 Jun 2019 10:06:00 -0400 In-Reply-To: <20190612063313.2729-1-tyos@jp.ibm.com> (Takeshi Yoshimura's message of "Wed, 12 Jun 2019 15:33:12 +0900") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.45]); Wed, 12 Jun 2019 14:06:11 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH] vfio: fix expanding DMA area in ppc64le 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" Takeshi Yoshimura writes: > In ppc64le, expanding DMA areas always fail because we cannot remove > a DMA window. As a result, we cannot allocate more than one memseg in > ppc64le. This is because vfio_spapr_dma_mem_map() doesn't unmap all > the mapped DMA before removing the window. This patch fixes this > incorrect behavior. > > I added a global variable to track current window size since we do > not have better ways to get exact size of it than doing so. sPAPR > IOMMU seems not to provide any ways to get window size with ioctl > interfaces. rte_memseg_walk*() is currently used to calculate window > size, but it walks memsegs that are marked as used, not mapped. So, > we need to determine if a given memseg is mapped or not, otherwise > the ioctl reports errors due to attempting to unregister memory > addresses that are not registered. The global variable is excluded > in non-ppc64le binaries. > > Similar problems happen in user maps. We need to avoid attempting to > unmap the address that is given as the function's parameter. The > compaction of user maps prevents us from passing correct length for > unmapping DMA at the window recreation. So, I removed it in ppc64le. > > I also fixed the order of ioctl for unregister and unmap. The ioctl > for unregister sometimes report device busy errors due to the > existence of mapped area. > > Signed-off-by: Takeshi Yoshimura > --- Hi Takeshi, I see the compilation with this patch has failed. See https://travis-ci.com/ovsrobot/dpdk/builds/115206950 for the jobs run.