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 C53E7A052A; Wed, 23 Dec 2020 06:13:58 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1052ACA34; Wed, 23 Dec 2020 06:13:57 +0100 (CET) Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) by dpdk.org (Postfix) with ESMTP id 281F0CA2E for ; Wed, 23 Dec 2020 06:13:55 +0100 (CET) Received: by mail-pl1-f179.google.com with SMTP id s15so4130844plr.9 for ; Tue, 22 Dec 2020 21:13:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=xqTw7FNYNlzhgNoiTOCTIys6MwqCr7YZ1dpEijzNqWA=; b=ITs/NvQCy0Tk8D8msPMLF7o03ConWdDI2y+5jA86yRxHfyg2pxrhXorx4wNqIE3x1N ZjGI+C80xPQsO4OutyVP29xtBEsbkKwI9BD5qXm3gkvbDfSikuBYbqVPt0cESwQxA3nl 6ecYrllKholcSDggaNl/2di1HZdcC5tcw3tzJ+u8k2OwnTd1yy8psMQxLNDfs9elq/eO H04XZUzr8BvRd2nLGV55FbLxeMN4UEOC7ETpzSFislcVtMPeORiF11RJ2wJjRnBRkHtp buUB4FcvsKT8Fb5r75u0U3X0aIhmELaqEt/4kfEhfdacTZaGCxj0JNaIT82kL+9igInp vt5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=xqTw7FNYNlzhgNoiTOCTIys6MwqCr7YZ1dpEijzNqWA=; b=BNVAyEe2tPyFuIZ+iZwU87gy+35VOoOHz35jf1Xsp9afPJ2fGMsin06Pzs2ADIbiP7 1Xm1uSagMab0tW0NLuSWfkhIQ8UuNvjodV3WeLCMTb0J6lGWQoYxxWN1GjJrvR14BIbE 738HA31XnCwC0RVOzlYQuG+UmYioStnzXTODszFKr2YdX/dTLb0c7Ns0npR6ZmTsmMyp 0PZ+uVwANw2uH9FnHlEEk1/xD5CFW2HbfCimM/+BRUqUloao5kmM3+44tcLJpjStjYZq 4+6hozqMyj26GBsd7XoztDrwy5lh98Z0uEuH99NsLwWCf1r+ybPiI6gOWyprQKXpj0lm 7VpQ== X-Gm-Message-State: AOAM533p9MDRUELuzpyVJeyMe+2DKpmi4nZiYj9pHmEOeNI4Nrj2anUG H/vm3XDsWPt+Hk2em0HKP7w= X-Google-Smtp-Source: ABdhPJx88+TDIpR/sGwCzONsO8tJatyhLAMHljmEnhUgH7iZhQcpWtKdgjdS1/OYR0Nz3zP+eiviPQ== X-Received: by 2002:a17:90b:b0d:: with SMTP id bf13mr25154539pjb.194.1608700433076; Tue, 22 Dec 2020 21:13:53 -0800 (PST) Received: from gmail.com ([1.6.215.26]) by smtp.gmail.com with ESMTPSA id y69sm21868653pfb.64.2020.12.22.21.13.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Dec 2020 21:13:52 -0800 (PST) Date: Wed, 23 Dec 2020 10:43:45 +0530 From: Nithin Dabilpuram To: anatoly.burakov@intel.com, David Christensen , david.marchand@redhat.com Cc: jerinj@marvell.com, dev@dpdk.org Message-ID: References: <20201012081106.10610-1-ndabilpuram@marvell.com> <20201217190604.29803-1-ndabilpuram@marvell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201217190604.29803-1-ndabilpuram@marvell.com> Subject: Re: [dpdk-dev] [PATCH v6 0/4] fix issue with partial DMA unmap 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" Ping. On Fri, Dec 18, 2020 at 12:36:00AM +0530, Nithin Dabilpuram wrote: > Partial DMA unmap is not supported by VFIO type1 IOMMU > in Linux. Though the return value is zero, the returned > DMA unmap size is not same as expected size. > So add test case and fix to both heap triggered DMA > mapping and user triggered DMA mapping/unmapping. > > Refer vfio_dma_do_unmap() in drivers/vfio/vfio_iommu_type1.c > Snippet of comment is below. > > /* > * vfio-iommu-type1 (v1) - User mappings were coalesced together to > * avoid tracking individual mappings. This means that the granularity > * of the original mapping was lost and the user was allowed to attempt > * to unmap any range. Depending on the contiguousness of physical > * memory and page sizes supported by the IOMMU, arbitrary unmaps may > * or may not have worked. We only guaranteed unmap granularity > * matching the original mapping; even though it was untracked here, > * the original mappings are reflected in IOMMU mappings. This > * resulted in a couple unusual behaviors. First, if a range is not > * able to be unmapped, ex. a set of 4k pages that was mapped as a > * 2M hugepage into the IOMMU, the unmap ioctl returns success but with > * a zero sized unmap. Also, if an unmap request overlaps the first > * address of a hugepage, the IOMMU will unmap the entire hugepage. > * This also returns success and the returned unmap size reflects the > * actual size unmapped. > > * We attempt to maintain compatibility with this "v1" interface, but > * we take control out of the hands of the IOMMU. Therefore, an unmap > * request offset from the beginning of the original mapping will > * return success with zero sized unmap. And an unmap request covering > * the first iova of mapping will unmap the entire range. > > This behavior can be verified by using first patch and add return check for > dma_unmap.size != len in vfio_type1_dma_mem_map() > > v6: > - Fixed issue with x86-32 build introduced by v5. > > v5: > - Changed vfio test in test_vfio.c to use system pages allocated from > heap instead of mmap() so that it comes in range of initially configured > window for POWER9 System. > - Added acked-by from David for 1/4, 2/4. > > v4: > - Fixed issue with patch 4/4 on x86 builds. > > v3: > - Fixed external memory test case(4/4) to use system page size > instead of 4K. > - Fixed check-git-log.sh issue and rebased. > - Added acked-by from anatoly.burakov@intel.com to first 3 patches. > > v2: > - Reverted earlier commit that enables mergin contiguous mapping for > IOVA as PA. (see 1/3) > - Updated documentation about kernel dma mapping limits and vfio > module parameter. > - Moved vfio test to test_vfio.c and handled comments from > Anatoly. > > Nithin Dabilpuram (4): > vfio: revert changes for map contiguous areas in one go > vfio: fix DMA mapping granularity for type1 IOVA as VA > test: add test case to validate VFIO DMA map/unmap > test: change external memory test to use system page sz > > app/test/meson.build | 1 + > app/test/test_external_mem.c | 3 +- > app/test/test_vfio.c | 107 +++++++++++++++++++++++++++++++++ > doc/guides/linux_gsg/linux_drivers.rst | 10 +++ > lib/librte_eal/linux/eal_vfio.c | 93 +++++++++++----------------- > lib/librte_eal/linux/eal_vfio.h | 1 + > 6 files changed, 157 insertions(+), 58 deletions(-) > create mode 100644 app/test/test_vfio.c > > -- > 2.8.4 >