linux-rdma.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Jianxin Xiong <jianxin.xiong@intel.com>
Cc: linux-rdma@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Doug Ledford <dledford@redhat.com>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	Sumit Semwal <sumit.semwal@linaro.org>,
	Christian Koenig <christian.koenig@amd.com>,
	Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [PATCH v14 1/4] RDMA/umem: Support importing dma-buf as user memory region
Date: Wed, 9 Dec 2020 08:30:38 +0200	[thread overview]
Message-ID: <20201209063038.GL4430@unreal> (raw)
In-Reply-To: <1607467155-92725-2-git-send-email-jianxin.xiong@intel.com>

On Tue, Dec 08, 2020 at 02:39:12PM -0800, Jianxin Xiong wrote:
> Dma-buf is a standard cross-driver buffer sharing mechanism that can be
> used to support peer-to-peer access from RDMA devices.
>
> Device memory exported via dma-buf is associated with a file descriptor.
> This is passed to the user space as a property associated with the
> buffer allocation. When the buffer is registered as a memory region,
> the file descriptor is passed to the RDMA driver along with other
> parameters.
>
> Implement the common code for importing dma-buf object and mapping
> dma-buf pages.
>
> Signed-off-by: Jianxin Xiong <jianxin.xiong@intel.com>
> Reviewed-by: Sean Hefty <sean.hefty@intel.com>
> Acked-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
> Acked-by: Christian Koenig <christian.koenig@amd.com>
> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
>  drivers/infiniband/core/Makefile      |   2 +-
>  drivers/infiniband/core/umem.c        |   3 +
>  drivers/infiniband/core/umem_dmabuf.c | 174 ++++++++++++++++++++++++++++++++++
>  include/rdma/ib_umem.h                |  47 ++++++++-
>  4 files changed, 222 insertions(+), 4 deletions(-)
>  create mode 100644 drivers/infiniband/core/umem_dmabuf.c

<...>

> +int ib_umem_dmabuf_map_pages(struct ib_umem_dmabuf *umem_dmabuf)
> +{
> +	struct sg_table *sgt;
> +	struct scatterlist *sg;
> +	struct dma_fence *fence;
> +	unsigned long start, end, cur = 0;
> +	unsigned int nmap = 0;
> +	int i;
> +
> +	dma_resv_assert_held(umem_dmabuf->attach->dmabuf->resv);
> +
> +	if (umem_dmabuf->sgt)
> +		goto wait_fence;
> +
> +	sgt = dma_buf_map_attachment(umem_dmabuf->attach, DMA_BIDIRECTIONAL);
> +	if (IS_ERR(sgt))
> +		return PTR_ERR(sgt);
> +
> +	/* modify the sg list in-place to match umem address and length */
> +
> +	start = ALIGN_DOWN(umem_dmabuf->umem.address, PAGE_SIZE);
> +	end = ALIGN(umem_dmabuf->umem.address + umem_dmabuf->umem.length,
> +		    PAGE_SIZE);
> +	for_each_sgtable_dma_sg(sgt, sg, i) {
> +		if (start < cur + sg_dma_len(sg) && cur < end)
> +			nmap++;
> +		if (cur <= start && start < cur + sg_dma_len(sg)) {
> +			unsigned long offset = start - cur;
> +
> +			umem_dmabuf->first_sg = sg;
> +			umem_dmabuf->first_sg_offset = offset;
> +			sg_dma_address(sg) += offset;
> +			sg_dma_len(sg) -= offset;
> +			cur += offset;
> +		}
> +		if (cur < end && end <= cur + sg_dma_len(sg)) {
> +			unsigned long trim = cur + sg_dma_len(sg) - end;
> +
> +			umem_dmabuf->last_sg = sg;
> +			umem_dmabuf->last_sg_trim = trim;
> +			sg_dma_len(sg) -= trim;
> +			break;
> +		}
> +		cur += sg_dma_len(sg);
> +	}
> +
> +	umem_dmabuf->umem.sg_head.sgl = umem_dmabuf->first_sg;
> +	umem_dmabuf->umem.sg_head.nents = nmap;
> +	umem_dmabuf->umem.nmap = nmap;
> +	umem_dmabuf->sgt = sgt;
> +
> +wait_fence:
> +	/*
> +	 * Although the sg list is valid now, the content of the pages
> +	 * may be not up-to-date. Wait for the exporter to finish
> +	 * the migration.
> +	 */
> +	fence = dma_resv_get_excl(umem_dmabuf->attach->dmabuf->resv);
> +	if (fence)
> +		return dma_fence_wait(fence, false);

You called to dma_buf_map_attachment() earlier in this function, so if
you return an error here, the dma_buf won't be unmapped in pagefault_dmabuf_mr()

Thanks

  reply	other threads:[~2020-12-09  6:31 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-08 22:39 [PATCH v14 0/4] RDMA: Add dma-buf support Jianxin Xiong
2020-12-08 22:39 ` [PATCH v14 1/4] RDMA/umem: Support importing dma-buf as user memory region Jianxin Xiong
2020-12-09  6:30   ` Leon Romanovsky [this message]
2020-12-09 18:07     ` Xiong, Jianxin
2020-12-08 22:39 ` [PATCH v14 2/4] RDMA/core: Add device method for registering dma-buf based " Jianxin Xiong
2020-12-08 22:39 ` [PATCH v14 3/4] RDMA/uverbs: Add uverbs command for dma-buf based MR registration Jianxin Xiong
2020-12-08 22:39 ` [PATCH v14 4/4] RDMA/mlx5: Support dma-buf based userspace memory region Jianxin Xiong
2020-12-09  6:44   ` Leon Romanovsky
2020-12-09 18:29     ` Xiong, Jianxin
2020-12-09  7:13   ` Yishai Hadas
2020-12-09 18:26     ` Xiong, Jianxin
2020-12-08 23:41 ` [PATCH v14 0/4] RDMA: Add dma-buf support Jason Gunthorpe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201209063038.GL4430@unreal \
    --to=leon@kernel.org \
    --cc=christian.koenig@amd.com \
    --cc=daniel.vetter@intel.com \
    --cc=dledford@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jgg@ziepe.ca \
    --cc=jianxin.xiong@intel.com \
    --cc=linux-rdma@vger.kernel.org \
    --cc=sumit.semwal@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).