From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id EEAB2A034F; Mon, 22 Feb 2021 10:42:19 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 71A1040041; Mon, 22 Feb 2021 10:42:19 +0100 (CET) Received: from mail-pg1-f178.google.com (mail-pg1-f178.google.com [209.85.215.178]) by mails.dpdk.org (Postfix) with ESMTP id C599F4003C for ; Mon, 22 Feb 2021 10:42:17 +0100 (CET) Received: by mail-pg1-f178.google.com with SMTP id o7so9890798pgl.1 for ; Mon, 22 Feb 2021 01:42:17 -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=2Zs/N3qqvEg+VCnb8x7ysvKG6RpKvVkZ4yyojcTSmS8=; b=mNbIEQbXVT7Ut8WnVd8cTFX/6khz2w7LyuVgyJm7EcSO+pJSp35ruHPz7jk1AEBSMb 3TXPgGHZC0vAJ22oskLzRpgXiA5KwWJxKR6WZf+uPsCu7ORDci7wKuHC1IVqVqssPzbU LCQGF5dOI9XVASmScQ3J44V30g3Z/G0c5zirJVLbyu1DCuu9pekaA/RT66xdtuErifyP Sxp2E9EtrlMU1kQuyVkP4a9i56bpepM8C1PAs+LdtXp/+vInpEi29JvrrtI86VfZuwsk 5d09jpH88tN6Nv7NrJyEJSJGibKMVcSHBAi61ixuhKj72CtOgmv6Ii0lHIZ7xbxMblgj nMiw== 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=2Zs/N3qqvEg+VCnb8x7ysvKG6RpKvVkZ4yyojcTSmS8=; b=HKxw8rCjd3glszStpq4AV+1On0AxoYhmXKmMbRv/Vt0D6HMlbCC++y3WS93+9G4isw 8SdZrwx0bglul9ZV9mPE+zVCh1O1NEfNsKhnoZxu5ZjnwoIWxcg67A2WVgnnaEKGnWL9 V8w0UzSCiQAiEMLXJEpX535HoLAZWOWtRu14gOzBe5DM8xmOeyougDaUZFXXntsk3+1/ Gy01Enoa8LZ/kugM2KExT+m0vYJsBxqnAinXzwlyUdG/8fNZSF2ZwM8A0UiNkBtTSJa6 HevU1r0/VDUZnvwKzT5WK9/N4QfhdfLlDl0+hOEDiLU9NgRvLKzquuVKxePQM8Ycz7Ya p7QQ== X-Gm-Message-State: AOAM532cJtw0ccrJICt129lnD8rOU2DayPptOVQ6MK4r45KYSdX8DO7G Kkmt78sderir4bA4Bjq6vlA= X-Google-Smtp-Source: ABdhPJzIN5nRmElkU28fjjGTSfGo/4U5ajUB7CpsYLvb6SaUeRnWatjA3RKgrbkMbAe7kx0HYKJelA== X-Received: by 2002:a63:515:: with SMTP id 21mr19098399pgf.231.1613986936860; Mon, 22 Feb 2021 01:42:16 -0800 (PST) Received: from gmail.com ([1.6.215.26]) by smtp.gmail.com with ESMTPSA id w9sm18361583pfc.51.2021.02.22.01.42.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Feb 2021 01:42:16 -0800 (PST) Date: Mon, 22 Feb 2021 15:11:46 +0530 From: Nithin Dabilpuram To: david.marchand@redhat.com Cc: David Christensen , david.marchand@redhat.com, jerinj@marvell.com, dev@dpdk.org, "Burakov, Anatoly" Message-ID: References: <20201012081106.10610-1-ndabilpuram@marvell.com> <20210115073243.7025-1-ndabilpuram@marvell.com> <9fa8f512-c00d-f8bc-5c5e-36581846bc78@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9fa8f512-c00d-f8bc-5c5e-36581846bc78@intel.com> Subject: Re: [dpdk-dev] [PATCH v8 0/3] fix issue with partial DMA unmap X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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. Can this be merged for 21.05 ? It is pending since few releases. -- Thanks Nihtin On Tue, Feb 16, 2021 at 01:14:37PM +0000, Burakov, Anatoly wrote: > On 15-Jan-21 7:32 AM, 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() > > > > v8: > > - Add cc stable to patch 3/3 > > > > v7: > > - Dropped vfio test case of patch 3/4 i.e > > "test: add test case to validate VFIO DMA map/unmap" > > as it couldn't be supported in POWER9 system. > > > > 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 (3): > > vfio: revert changes for map contiguous areas in one go > > vfio: fix DMA mapping granularity for type1 IOVA as VA > > test: change external memory test to use system page sz > > > > Is there anything preventing this from getting merged? Let's try for 21.05 > :) > > -- > Thanks, > Anatoly