From: Robin Murphy <robin.murphy@arm.com>
To: Leon Romanovsky <leon@kernel.org>,
Alex Williamson <alex.williamson@redhat.com>
Cc: "Leon Romanovsky" <leonro@nvidia.com>,
"Christoph Hellwig" <hch@lst.de>,
"Jason Gunthorpe" <jgg@nvidia.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Christian König" <christian.koenig@amd.com>,
dri-devel@lists.freedesktop.org, iommu@lists.linux.dev,
"Jens Axboe" <axboe@kernel.dk>,
"Jérôme Glisse" <jglisse@redhat.com>,
"Joerg Roedel" <joro@8bytes.org>,
kvm@vger.kernel.org, linaro-mm-sig@lists.linaro.org,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-media@vger.kernel.org, linux-mm@kvack.org,
linux-pci@vger.kernel.org,
"Logan Gunthorpe" <logang@deltatee.com>,
"Marek Szyprowski" <m.szyprowski@samsung.com>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Vivek Kasireddy" <vivek.kasireddy@intel.com>,
"Will Deacon" <will@kernel.org>
Subject: Re: [PATCH 10/10] vfio/pci: Add dma-buf export support for MMIO regions
Date: Tue, 29 Jul 2025 20:44:21 +0100 [thread overview]
Message-ID: <8f912671-f1d9-4f73-9c1d-e39938bfc09f@arm.com> (raw)
In-Reply-To: <aea452cc27ca9e5169f7279d7b524190c39e7260.1753274085.git.leonro@nvidia.com>
On 2025-07-23 2:00 pm, Leon Romanovsky wrote:
[...]
> +static struct sg_table *
> +vfio_pci_dma_buf_map(struct dma_buf_attachment *attachment,
> + enum dma_data_direction dir)
> +{
> + struct vfio_pci_dma_buf *priv = attachment->dmabuf->priv;
> + struct p2pdma_provider *provider = priv->vdev->provider;
> + struct dma_iova_state *state = attachment->priv;
> + struct phys_vec *phys_vec = &priv->phys_vec;
> + struct scatterlist *sgl;
> + struct sg_table *sgt;
> + dma_addr_t addr;
> + int ret;
> +
> + dma_resv_assert_held(priv->dmabuf->resv);
> +
> + sgt = kzalloc(sizeof(*sgt), GFP_KERNEL);
> + if (!sgt)
> + return ERR_PTR(-ENOMEM);
> +
> + ret = sg_alloc_table(sgt, 1, GFP_KERNEL | __GFP_ZERO);
> + if (ret)
> + goto err_kfree_sgt;
> +
> + sgl = sgt->sgl;
> +
> + if (!state) {
> + addr = pci_p2pdma_bus_addr_map(provider, phys_vec->paddr);
> + } else if (dma_use_iova(state)) {
> + ret = dma_iova_link(attachment->dev, state, phys_vec->paddr, 0,
> + phys_vec->len, dir, DMA_ATTR_SKIP_CPU_SYNC);
The supposed benefits of this API are only for replacing scatterlists
where multiple disjoint pages are being mapped. In this case with just
one single contiguous mapping, it is clearly objectively worse to have
to bounce in and out of the IOMMU layer 3 separate times and store a
dma_map_state, to achieve the exact same operations that a single call
to iommu_dma_map_resource() will perform more efficiently and with no
external state required.
Oh yeah, and mapping MMIO with regular memory attributes (IOMMU_CACHE)
rather than appropriate ones (IOMMU_MMIO), as this will end up doing,
isn't guaranteed not to end badly either (e.g. if the system
interconnect ends up merging consecutive write bursts and exceeding the
target root port's MPS.)
> + if (ret)
> + goto err_free_table;
> +
> + ret = dma_iova_sync(attachment->dev, state, 0, phys_vec->len);
> + if (ret)
> + goto err_unmap_dma;
> +
> + addr = state->addr;
> + } else {
> + addr = dma_map_phys(attachment->dev, phys_vec->paddr,
> + phys_vec->len, dir, DMA_ATTR_SKIP_CPU_SYNC);
And again, if the IOMMU is in bypass (the idea of P2P with vfio-noiommu
simply isn't worth entertaining) then what purpose do you imagine this
call serves at all, other than to hilariously crash under
"swiotlb=force"? Even in the case that phys_to_dma(phys_vec->paddr) !=
phys_vec->paddr, in almost all circumstances (both hardware offsets and
CoCo environments with address-based aliasing), it is more likely than
not that the latter is still the address you want and the former is
wrong (and liable to lead to corruption or fatal system errors), because
MMIO and memory remain fundamentally different things.
AFAICS you're *depending* on this call being an effective no-op, and
thus only demonstrating that the dma_map_phys() idea is still entirely
unnecessary.
> + ret = dma_mapping_error(attachment->dev, addr);
> + if (ret)
> + goto err_free_table;
> + }
> +
> + fill_sg_entry(sgl, phys_vec->len, addr);
> + return sgt;
> +
> +err_unmap_dma:
> + dma_iova_destroy(attachment->dev, state, phys_vec->len, dir,
> + DMA_ATTR_SKIP_CPU_SYNC);
> +err_free_table:
> + sg_free_table(sgt);
> +err_kfree_sgt:
> + kfree(sgt);
> + return ERR_PTR(ret);
> +}
> +
> +static void vfio_pci_dma_buf_unmap(struct dma_buf_attachment *attachment,
> + struct sg_table *sgt,
> + enum dma_data_direction dir)
> +{
> + struct vfio_pci_dma_buf *priv = attachment->dmabuf->priv;
> + struct dma_iova_state *state = attachment->priv;
> + struct scatterlist *sgl;
> + int i;
> +
> + if (!state)
> + ; /* Do nothing */
> + else if (dma_use_iova(state))
> + dma_iova_destroy(attachment->dev, state, priv->phys_vec.len,
> + dir, DMA_ATTR_SKIP_CPU_SYNC);
> + else
> + for_each_sgtable_dma_sg(sgt, sgl, i)
The table always has exactly one entry...
Thanks,
Robin.
> + dma_unmap_phys(attachment->dev, sg_dma_address(sgl),
> + sg_dma_len(sgl), dir,
> + DMA_ATTR_SKIP_CPU_SYNC);
> +
> + sg_free_table(sgt);
> + kfree(sgt);
> +}
next prev parent reply other threads:[~2025-07-29 19:44 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-23 13:00 [PATCH 00/10] vfio/pci: Allow MMIO regions to be exported through dma-buf Leon Romanovsky
2025-07-23 13:00 ` [PATCH 01/10] PCI/P2PDMA: Remove redundant bus_offset from map state Leon Romanovsky
2025-07-24 7:50 ` Christoph Hellwig
2025-07-23 13:00 ` [PATCH 02/10] PCI/P2PDMA: Introduce p2pdma_provider structure for cleaner abstraction Leon Romanovsky
2025-07-24 7:51 ` Christoph Hellwig
2025-07-24 7:55 ` Leon Romanovsky
2025-07-24 7:59 ` Christoph Hellwig
2025-07-24 8:07 ` Leon Romanovsky
2025-07-27 18:51 ` Jason Gunthorpe
2025-07-29 7:52 ` Christoph Hellwig
2025-07-29 8:53 ` Leon Romanovsky
2025-07-29 10:41 ` Christoph Hellwig
2025-07-29 11:39 ` Leon Romanovsky
2025-07-29 13:15 ` Jason Gunthorpe
2025-07-29 16:12 ` Jason Gunthorpe
2025-07-23 13:00 ` [PATCH 03/10] PCI/P2PDMA: Simplify bus address mapping API Leon Romanovsky
2025-07-24 7:52 ` Christoph Hellwig
2025-07-23 13:00 ` [PATCH 04/10] PCI/P2PDMA: Refactor to separate core P2P functionality from memory allocation Leon Romanovsky
2025-07-23 13:00 ` [PATCH 05/10] PCI/P2PDMA: Export pci_p2pdma_map_type() function Leon Romanovsky
2025-07-24 8:03 ` Christoph Hellwig
2025-07-24 8:13 ` Leon Romanovsky
2025-07-25 16:30 ` Logan Gunthorpe
2025-07-25 18:54 ` Leon Romanovsky
2025-07-25 19:12 ` Logan Gunthorpe
2025-07-27 6:01 ` Leon Romanovsky
2025-07-27 19:05 ` Jason Gunthorpe
2025-07-28 16:12 ` Logan Gunthorpe
2025-07-28 16:41 ` Leon Romanovsky
2025-07-28 17:07 ` Logan Gunthorpe
2025-07-28 23:11 ` Jason Gunthorpe
2025-07-29 20:54 ` Logan Gunthorpe
2025-07-29 22:14 ` Jason Gunthorpe
2025-07-30 8:03 ` Leon Romanovsky
2025-07-29 7:52 ` Christoph Hellwig
2025-07-29 8:45 ` Leon Romanovsky
2025-07-27 19:02 ` Jason Gunthorpe
2025-07-23 13:00 ` [PATCH 06/10] types: move phys_vec definition to common header Leon Romanovsky
2025-07-23 13:00 ` [PATCH 07/10] vfio: Export vfio device get and put registration helpers Leon Romanovsky
2025-07-23 13:00 ` [PATCH 08/10] vfio/pci: Enable peer-to-peer DMA transactions by default Leon Romanovsky
2025-07-23 13:00 ` [PATCH 09/10] vfio/pci: Share the core device pointer while invoking feature functions Leon Romanovsky
2025-07-28 20:55 ` Alex Williamson
2025-07-29 8:39 ` Leon Romanovsky
2025-07-23 13:00 ` [PATCH 10/10] vfio/pci: Add dma-buf export support for MMIO regions Leon Romanovsky
2025-07-24 5:13 ` Kasireddy, Vivek
2025-07-24 5:44 ` Leon Romanovsky
2025-07-25 5:34 ` Kasireddy, Vivek
2025-07-27 6:16 ` Leon Romanovsky
2025-07-29 19:44 ` Robin Murphy [this message]
2025-07-29 20:13 ` Jason Gunthorpe
2025-07-30 9:32 ` Leon Romanovsky
2025-07-30 14:49 ` Robin Murphy
2025-07-30 16:01 ` Jason Gunthorpe
2025-07-30 19:58 ` [PATCH 00/10] vfio/pci: Allow MMIO regions to be exported through dma-buf Alex Williamson
2025-07-31 0:21 ` 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=8f912671-f1d9-4f73-9c1d-e39938bfc09f@arm.com \
--to=robin.murphy@arm.com \
--cc=akpm@linux-foundation.org \
--cc=alex.williamson@redhat.com \
--cc=axboe@kernel.dk \
--cc=bhelgaas@google.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=hch@lst.de \
--cc=iommu@lists.linux.dev \
--cc=jgg@nvidia.com \
--cc=jglisse@redhat.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=leon@kernel.org \
--cc=leonro@nvidia.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-pci@vger.kernel.org \
--cc=logang@deltatee.com \
--cc=m.szyprowski@samsung.com \
--cc=sumit.semwal@linaro.org \
--cc=vivek.kasireddy@intel.com \
--cc=will@kernel.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