linux-rdma.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Yan Zhao <yan.y.zhao@intel.com>
Cc: "Alex Williamson" <alex.williamson@redhat.com>,
	"Christian König" <christian.koenig@amd.com>,
	"Cornelia Huck" <cohuck@redhat.com>,
	dri-devel@lists.freedesktop.org, kvm@vger.kernel.org,
	linaro-mm-sig@lists.linaro.org, linux-media@vger.kernel.org,
	"Sumit Semwal" <sumit.semwal@linaro.org>,
	"Daniel Vetter" <daniel.vetter@ffwll.ch>,
	"Leon Romanovsky" <leon@kernel.org>,
	linux-rdma@vger.kernel.org, "Maor Gottlieb" <maorg@nvidia.com>,
	"Oded Gabbay" <ogabbay@kernel.org>
Subject: Re: [PATCH 4/4] vfio/pci: Allow MMIO regions to be exported through dma-buf
Date: Mon, 29 Aug 2022 09:26:41 -0300	[thread overview]
Message-ID: <YwywgciH6BiWz4H1@nvidia.com> (raw)
In-Reply-To: <YwxIxWQQ/ENiFak+@yzhao56-desk.sh.intel.com>

On Mon, Aug 29, 2022 at 01:04:05PM +0800, Yan Zhao wrote:

> > +static struct sg_table *
> > +vfio_pci_dma_buf_map(struct dma_buf_attachment *attachment,
> > +		     enum dma_data_direction dir)
> > +{
> > +	size_t sgl_size = dma_get_max_seg_size(attachment->dev);
> > +	struct vfio_pci_dma_buf *priv = attachment->dmabuf->priv;
> > +	struct scatterlist *sgl;
> > +	struct sg_table *sgt;
> > +	dma_addr_t dma_addr;
> > +	unsigned int nents;
> > +	size_t offset;
> > +	int ret;
> > +
> > +	dma_resv_assert_held(priv->dmabuf->resv);
> > +
> > +	if (!attachment->peer2peer)
> > +		return ERR_PTR(-EPERM);
> > +
> > +	if (!priv->revoked)
> > +		return ERR_PTR(-ENODEV);
> > +
> > +	sgt = kzalloc(sizeof(*sgt), GFP_KERNEL);
> > +	if (!sgt)
> > +		return ERR_PTR(-ENOMEM);
> > +
> > +	nents = DIV_ROUND_UP(priv->dmabuf->size, sgl_size);
> > +	ret = sg_alloc_table(sgt, nents, GFP_KERNEL);
> > +	if (ret)
> > +		goto err_kfree_sgt;
> > +
> > +	/*
> > +	 * Since the memory being mapped is a device memory it could never be in
> > +	 * CPU caches.
> > +	 */
> > +	dma_addr = dma_map_resource(
> > +		attachment->dev,
> > +		pci_resource_start(priv->vdev->pdev, priv->index) +
> > +			priv->offset,
> > +		priv->dmabuf->size, dir, DMA_ATTR_SKIP_CPU_SYNC);
> dma_map_resource maps the phys to an IOVA in device's
> default_domain, which, however, may not be the domain that the device is
> currently attached to.

dmabuf is defined only in terms of the DMA API, so it creates a SGL
with DMA API mapped dma_addr's

> So, the importer of this sgt will convert this dma_addr back to phys?

No, it is illegal to call this API if the importer is not using the
DMA API.

I'm expecting to propose some new dmabuf API for this use-case, when
we get to it. For now all importers use the DMA API.

> BTW, I don't see the assignment of priv->index in below
> vfio_pci_core_feature_dma_buf(), is it equal to
> get_dma_buf.region_index ?

Yes, I noticed that too and have fixed it - the testing was all done
on index 0.

Jason

  reply	other threads:[~2022-08-29 12:42 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-17 16:11 [PATCH 0/4] Allow MMIO regions to be exported through dma-buf Jason Gunthorpe
2022-08-17 16:11 ` [PATCH 1/4] dma-buf: Add dma_buf_try_get() Jason Gunthorpe
2022-08-17 16:11 ` [PATCH 2/4] vfio: Add vfio_device_get() Jason Gunthorpe
2022-08-17 16:11 ` [PATCH 3/4] vfio_pci: Do not open code pci_try_reset_function() Jason Gunthorpe
2022-08-17 16:11 ` [PATCH 4/4] vfio/pci: Allow MMIO regions to be exported through dma-buf Jason Gunthorpe
2022-08-21 13:51   ` Fwd: " Oded Gabbay
2022-08-26 18:10     ` Jason Gunthorpe
2022-08-29  5:04   ` Yan Zhao
2022-08-29 12:26     ` Jason Gunthorpe [this message]
2022-08-18 11:07 ` [PATCH 0/4] " Christian König
2022-08-18 12:03   ` Jason Gunthorpe
2022-08-18 12:58     ` Christian König
2022-08-18 13:16       ` Jason Gunthorpe
2022-08-18 13:37         ` Christian König
2022-08-19 13:11           ` Jason Gunthorpe
2022-08-19 13:33             ` Christian König
2022-08-19 13:39               ` Jason Gunthorpe
2022-08-19 13:47                 ` Christian König
2022-08-18 12:05 ` Jason Gunthorpe
2022-08-22 21:58   ` Alex Williamson

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=YwywgciH6BiWz4H1@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=alex.williamson@redhat.com \
    --cc=christian.koenig@amd.com \
    --cc=cohuck@redhat.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kvm@vger.kernel.org \
    --cc=leon@kernel.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=maorg@nvidia.com \
    --cc=ogabbay@kernel.org \
    --cc=sumit.semwal@linaro.org \
    --cc=yan.y.zhao@intel.com \
    /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).