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 24F59A054F; Mon, 1 Mar 2021 13:13:48 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id AC04B22A257; Mon, 1 Mar 2021 13:13:47 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by mails.dpdk.org (Postfix) with ESMTP id 5199022A23C for ; Mon, 1 Mar 2021 13:13:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1614600825; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=8D15zkbjC6v2eAI1M4yP73z5u7U6CJZ2XaiPWW+L/oc=; b=d5ZN7h9pYcSm/5apCclm0T9fhqKWwPzaVoNXSIsj+TCrhIGge9PTL5vD7RudWY6kE2OEAK 6ntPU+Omud72vuqTX4AQrxxg+jiI+0qbm0opRYgdD46Ve9eH8RN2RdO2ifhgHuu5E0fu2g BU0Q4QF52B3Dp2pPqqGRhPvC9A2WlZ0= Received: from mail-ua1-f70.google.com (mail-ua1-f70.google.com [209.85.222.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-108-1LjD-xt8OuCxT8kzivgnWA-1; Mon, 01 Mar 2021 07:13:44 -0500 X-MC-Unique: 1LjD-xt8OuCxT8kzivgnWA-1 Received: by mail-ua1-f70.google.com with SMTP id q14so853095uao.21 for ; Mon, 01 Mar 2021 04:13:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8D15zkbjC6v2eAI1M4yP73z5u7U6CJZ2XaiPWW+L/oc=; b=cF6CcNV/u1CmVcVxm3BLDqY9tRwHKWIUwesRala5kfocxyQuAWRNv9hypHt/VHZA86 HhBPd9vmDdTDb/xB6noszFhHGbBM3kWhHx0uDMRmfyFBbJs899dYttswTAe8kxqjRLFY DBA8Br1KZ6bOY+wlSZkVwzGzQtC/WfIknzU0RUoO+CUiRK5zRL9tFb0/fphPrneKHVpT 0xHqu5I/zB35TiU8LK3Vx4yHVE5H4Nuo5Ppbqz+22DK3MPxUDaUFlS8Av9dFe04jpmMG KK++2k6npuI80v8V/5PmfjAx9acCr/LFekPuYfvNt7vhm3J4I0LYbVTJOVFrLnGuzJFh iT6w== X-Gm-Message-State: AOAM532Bdb8MkRNEZh2tlhrCAlRbo3y1acvmCO0Nfdw0zZqX7EQXZAzh O8yZPg/I5/j2lo+Z20VVoSFJUBahg+SV/hbNfkwJv/euvtrL3yKOCQsUR+nmCUwrSB2DFHtpqUX n6MXTzsNRS5p5f7kOn2A= X-Received: by 2002:a67:8ec7:: with SMTP id q190mr8095556vsd.10.1614600823818; Mon, 01 Mar 2021 04:13:43 -0800 (PST) X-Google-Smtp-Source: ABdhPJyDixworpidNDekj/+F8Ig6GP0hsn5XyKDF1GOSX/bMLzycWPjccv56WfKmbT/7E3fgzc68tlk/9dsX3tlGrpM= X-Received: by 2002:a67:8ec7:: with SMTP id q190mr8095548vsd.10.1614600823559; Mon, 01 Mar 2021 04:13:43 -0800 (PST) MIME-Version: 1.0 References: <20201012081106.10610-1-ndabilpuram@marvell.com> <20210115073243.7025-1-ndabilpuram@marvell.com> In-Reply-To: <20210115073243.7025-1-ndabilpuram@marvell.com> From: David Marchand Date: Mon, 1 Mar 2021 13:13:32 +0100 Message-ID: To: Nithin Dabilpuram Cc: "Burakov, Anatoly" , David Christensen , Jerin Jacob Kollanukkaran , dev Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" 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" On Fri, Jan 15, 2021 at 8:33 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() Series applied, thanks. -- David Marchand