Re: [PATCH v1 2/2] vfio/pci: Allow MMIO regions to be exported through dma-buf
On Tue, May 07, 2024 at 09:31:53PM -0300, Jason Gunthorpe wrote:
> On Thu, May 02, 2024 at 07:50:36AM +, Kasireddy, Vivek wrote:
> > Hi Jason,
> >
> > >
> > > On Tue, Apr 30, 2024 at 04:24:50PM -0600, Alex Williamson wrote:
> > > > > +static vm_fault_t vfio_pci_dma_buf_fault(struct vm_fault *vmf)
> > > > > +{
> > > > > + struct vm_area_struct *vma = vmf->vma;
> > > > > + struct vfio_pci_dma_buf *priv = vma->vm_private_data;
> > > > > + pgoff_t pgoff = vmf->pgoff;
> > > > > +
> > > > > + if (pgoff >= priv->nr_pages)
> > > > > + return VM_FAULT_SIGBUS;
> > > > > +
> > > > > + return vmf_insert_pfn(vma, vmf->address,
> > > > > + page_to_pfn(priv->pages[pgoff]));
> > > > > +}
> > > >
> > > > How does this prevent the MMIO space from being mmap'd when disabled
> > > at
> > > > the device? How is the mmap revoked when the MMIO becomes disabled?
> > > > Is it part of the move protocol?
> > In this case, I think the importers that mmap'd the dmabuf need to be
> > tracked
> > separately and their VMA PTEs need to be zapped when MMIO access is revoked.
>
> Which, as we know, is quite hard.
>
> > > Yes, we should not have a mmap handler for dmabuf. vfio memory must be
> > > mmapped in the normal way.
> > Although optional, I think most dmabuf exporters (drm ones) provide a mmap
> > handler. Otherwise, there is no easy way to provide CPU access (backup slow
> > path)
> > to the dmabuf for the importer.
>
> Here we should not, there is no reason since VFIO already provides a
> mmap mechanism itself. Anything using this API should just call the
> native VFIO function instead of trying to mmap the DMABUF. Yes, it
> will be inconvient for the scatterlist case you have, but the kernel
> side implementation is much easier ..
Just wanted to confirm that it's entirely legit to not implement dma-buf
mmap. Same for the in-kernel vmap functions. Especially for really funny
buffers like these it's just not a good idea, and the dma-buf interfaces
are intentionally "everything is optional".
Similarly you can (and should) reject and dma_buf_attach to devices where
p2p connectevity isn't there, or well really for any other reason that
makes stuff complicated and is out of scope for your use-case. It's better
to reject strictly and than accidentally support something really horrible
(we've been there).
The only real rule with all the interfaces is that when attach() worked,
then map must too (except when you're in OOM). Because at least for some
drivers/subsystems, that's how userspace figures out whether a buffer can
be shared.
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v1 2/2] vfio/pci: Allow MMIO regions to be exported through dma-buf
On Thu, May 02, 2024 at 07:50:36AM +, Kasireddy, Vivek wrote:
> Hi Jason,
>
> >
> > On Tue, Apr 30, 2024 at 04:24:50PM -0600, Alex Williamson wrote:
> > > > +static vm_fault_t vfio_pci_dma_buf_fault(struct vm_fault *vmf)
> > > > +{
> > > > + struct vm_area_struct *vma = vmf->vma;
> > > > + struct vfio_pci_dma_buf *priv = vma->vm_private_data;
> > > > + pgoff_t pgoff = vmf->pgoff;
> > > > +
> > > > + if (pgoff >= priv->nr_pages)
> > > > + return VM_FAULT_SIGBUS;
> > > > +
> > > > + return vmf_insert_pfn(vma, vmf->address,
> > > > + page_to_pfn(priv->pages[pgoff]));
> > > > +}
> > >
> > > How does this prevent the MMIO space from being mmap'd when disabled
> > at
> > > the device? How is the mmap revoked when the MMIO becomes disabled?
> > > Is it part of the move protocol?
> In this case, I think the importers that mmap'd the dmabuf need to be tracked
> separately and their VMA PTEs need to be zapped when MMIO access is revoked.
Which, as we know, is quite hard.
> > Yes, we should not have a mmap handler for dmabuf. vfio memory must be
> > mmapped in the normal way.
> Although optional, I think most dmabuf exporters (drm ones) provide a mmap
> handler. Otherwise, there is no easy way to provide CPU access (backup slow
> path)
> to the dmabuf for the importer.
Here we should not, there is no reason since VFIO already provides a
mmap mechanism itself. Anything using this API should just call the
native VFIO function instead of trying to mmap the DMABUF. Yes, it
will be inconvient for the scatterlist case you have, but the kernel
side implementation is much easier ..
> > > > +/**
> > > > + * Upon VFIO_DEVICE_FEATURE_GET create a dma_buf fd for the
> > > > + * region selected.
> > > > + *
> > > > + * open_flags are the typical flags passed to open(2), eg O_RDWR,
> > O_CLOEXEC,
> > > > + * etc. offset/length specify a slice of the region to create the
> > > > dmabuf
> > from.
> > > > + * If both are 0 then the whole region is used.
> > > > + *
> > > > + * Return: The fd number on success, -1 and errno is set on failure.
> > > > + */
> > > > +#define VFIO_DEVICE_FEATURE_DMA_BUF 11
> > > > +
> > > > +struct vfio_region_p2p_area {
> > > > + __u32 region_index;
> > > > + __u32 __pad;
> > > > + __u64 offset;
> > > > + __u64 length;
> > > > +};
> > > > +
> > > > +struct vfio_device_feature_dma_buf {
> > > > + __u32 open_flags;
> > > > + __u32 nr_areas;
> > > > + struct vfio_region_p2p_area p2p_areas[];
> > > > +};
> >
> > Still have no clue what this p2p areas is. You want to create a dmabuf
> > out of a scatterlist? Why??
> Because the data associated with a buffer that needs to be shared can
> come from multiple ranges. I probably should have used the terms ranges
> or slices or chunks to make it more clear instead of p2p areas.
Yes, please pick a better name.
> > I'm also not sure of the use of the pci_p2pdma family of functions, it
> > is a bold step to make struct pages, that isn't going to work in quite
> I guess things may have changed since the last discussion on this topic or
> maybe I misunderstood but I thought Christoph's suggestion was to use
> struct pages to populate the scatterlist instead of using DMA addresses
> and, I figured pci_p2pdma APIs can easily help with that.
It was, but it doesn't really work for VFIO. You can only create
struct pages for large MMIO spaces, and only on some architectures.
Requiring them will make VFIO unusable in alot of places. Requiring
them just for DMABUF will make that feature unusable.
Creating them on first use, and then ignoring how broken it is
perhaps reasonable for now, but I'm unhappy to see it so poorly
usable.
>
> > alot of cases. It is really hacky/wrong to immediately call
> > pci_alloc_p2pmem() to defeat the internal genalloc.
> In my use-case, I need to use all the pages from the pool and I don't see any
> better way to do it.
You have to fix the P2P API to work properly for this kind of use
case.
There should be no genalloc at all.
> > I'd rather we stick with the original design. Leon is working on DMA
> > API changes that should address half the issue.
>
> Ok, I'll keep an eye out for Leon's work.
It saves from messing with the P2P stuff, but you get the other issues
back.
Jason
Re: [PATCH v1 2/2] vfio/pci: Allow MMIO regions to be exported through dma-buf
On Thu, May 02, 2024 at 07:50:36AM +, Kasireddy, Vivek wrote: > Hi Jason, <...> > > I'd rather we stick with the original design. Leon is working on DMA > > API changes that should address half the issue. > Ok, I'll keep an eye out for Leon's work. The code for v1 is here: https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git/log/?h=dma-split-v1 It is constantly rebased till we will be ready to submit it. v0 is here: https://lore.kernel.org/linux-rdma/cover.1709635535.git.l...@kernel.org/ Thanks > > Thanks, > Vivek > > > > > Jason >
RE: [PATCH v1 2/2] vfio/pci: Allow MMIO regions to be exported through dma-buf
Hi Jason,
>
> On Tue, Apr 30, 2024 at 04:24:50PM -0600, Alex Williamson wrote:
> > > +static vm_fault_t vfio_pci_dma_buf_fault(struct vm_fault *vmf)
> > > +{
> > > + struct vm_area_struct *vma = vmf->vma;
> > > + struct vfio_pci_dma_buf *priv = vma->vm_private_data;
> > > + pgoff_t pgoff = vmf->pgoff;
> > > +
> > > + if (pgoff >= priv->nr_pages)
> > > + return VM_FAULT_SIGBUS;
> > > +
> > > + return vmf_insert_pfn(vma, vmf->address,
> > > + page_to_pfn(priv->pages[pgoff]));
> > > +}
> >
> > How does this prevent the MMIO space from being mmap'd when disabled
> at
> > the device? How is the mmap revoked when the MMIO becomes disabled?
> > Is it part of the move protocol?
In this case, I think the importers that mmap'd the dmabuf need to be tracked
separately and their VMA PTEs need to be zapped when MMIO access is revoked.
>
> Yes, we should not have a mmap handler for dmabuf. vfio memory must be
> mmapped in the normal way.
Although optional, I think most dmabuf exporters (drm ones) provide a mmap
handler. Otherwise, there is no easy way to provide CPU access (backup slow
path)
to the dmabuf for the importer.
>
> > > +static void vfio_pci_dma_buf_release(struct dma_buf *dmabuf)
> > > +{
> > > + struct vfio_pci_dma_buf *priv = dmabuf->priv;
> > > +
> > > + /*
> > > + * Either this or vfio_pci_dma_buf_cleanup() will remove from the
> list.
> > > + * The refcount prevents both.
> > > + */
> > > + if (priv->vdev) {
> > > + release_p2p_pages(priv, priv->nr_pages);
> > > + kfree(priv->pages);
> > > + down_write(>vdev->memory_lock);
> > > + list_del_init(>dmabufs_elm);
> > > + up_write(>vdev->memory_lock);
> >
> > Why are we acquiring and releasing the memory_lock write lock
> > throughout when we're not modifying the device memory enable state?
> > Ugh, we're using it to implicitly lock dmabufs_elm/dmabufs aren't we...
>
> Not really implicitly, but yes the dmabufs list is locked by the
> memory_lock.
>
> > > +int vfio_pci_core_feature_dma_buf(struct vfio_pci_core_device *vdev,
> u32 flags,
> > > + struct vfio_device_feature_dma_buf __user
> *arg,
> > > + size_t argsz)
> > > +{
> > > + struct vfio_device_feature_dma_buf get_dma_buf;
> > > + struct vfio_region_p2p_area *p2p_areas;
> > > + DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
> > > + struct vfio_pci_dma_buf *priv;
> > > + int i, ret;
> > > +
> > > + ret = vfio_check_feature(flags, argsz, VFIO_DEVICE_FEATURE_GET,
> > > + sizeof(get_dma_buf));
> > > + if (ret != 1)
> > > + return ret;
> > > +
> > > + if (copy_from_user(_dma_buf, arg, sizeof(get_dma_buf)))
> > > + return -EFAULT;
> > > +
> > > + p2p_areas = memdup_array_user(>p2p_areas,
> > > + get_dma_buf.nr_areas,
> > > + sizeof(*p2p_areas));
> > > + if (IS_ERR(p2p_areas))
> > > + return PTR_ERR(p2p_areas);
> > > +
> > > + priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> > > + if (!priv)
> > > + return -ENOMEM;
> >
> > p2p_areas is leaked.
>
> What is this new p2p_areas thing? It wasn't in my patch..
As noted in the commit message, this is one of the things I added to
your original patch.
>
> > > + exp_info.ops = _pci_dmabuf_ops;
> > > + exp_info.size = priv->nr_pages << PAGE_SHIFT;
> > > + exp_info.flags = get_dma_buf.open_flags;
> >
> > open_flags from userspace are unchecked.
>
> Huh. That seems to be a dmabuf pattern. :\
>
> > > + exp_info.priv = priv;
> > > +
> > > + priv->dmabuf = dma_buf_export(_info);
> > > + if (IS_ERR(priv->dmabuf)) {
> > > + ret = PTR_ERR(priv->dmabuf);
> > > + goto err_free_pages;
> > > + }
> > > +
> > > + /* dma_buf_put() now frees priv */
> > > + INIT_LIST_HEAD(>dmabufs_elm);
> > > + down_write(>memory_lock);
> > > + dma_resv_lock(priv->dmabuf->resv, NULL);
> > > + priv->revoked = !__vfio_pci_memory_enabled(vdev);
> > > + vfio_device_try_get_registration(>vdev);
> >
> > I guess we're assuming this can't fail in the ioctl path of an open
> > device?
>
> Seems like a bug added here.. My version had this as
> vfio_device_get(). This stuff has probably changed since I wrote it.
vfio_device_try_get_registration() is essentially doing the same thing as
vfio_device_get() except that we need check the return value of
vfio_device_try_get_registration() which I plan to do in v2.
>
> > > + list_add_tail(>dmabufs_elm, >dmabufs);
> > > + dma_resv_unlock(priv->dmabuf->resv);
> >
> > What was the purpose of locking this?
>
> ?
>
> > > +void vfio_pci_dma_buf_move(struct vfio_pci_core_device *vdev, bool
> revoked)
> > > +{
> > > + struct vfio_pci_dma_buf *priv;
> > > + struct vfio_pci_dma_buf *tmp;
> > > +
> > > + lockdep_assert_held_write(>memory_lock);
> > > +
> > > + list_for_each_entry_safe(priv, tmp, >dmabufs, dmabufs_elm)
> {
> > > + if (!get_file_rcu(>dmabuf->file))
> > > + continue;
> >
> > Does
Re: [PATCH v1 2/2] vfio/pci: Allow MMIO regions to be exported through dma-buf
On Tue, Apr 30, 2024 at 04:24:50PM -0600, Alex Williamson wrote:
> > +static vm_fault_t vfio_pci_dma_buf_fault(struct vm_fault *vmf)
> > +{
> > + struct vm_area_struct *vma = vmf->vma;
> > + struct vfio_pci_dma_buf *priv = vma->vm_private_data;
> > + pgoff_t pgoff = vmf->pgoff;
> > +
> > + if (pgoff >= priv->nr_pages)
> > + return VM_FAULT_SIGBUS;
> > +
> > + return vmf_insert_pfn(vma, vmf->address,
> > + page_to_pfn(priv->pages[pgoff]));
> > +}
>
> How does this prevent the MMIO space from being mmap'd when disabled at
> the device? How is the mmap revoked when the MMIO becomes disabled?
> Is it part of the move protocol?
Yes, we should not have a mmap handler for dmabuf. vfio memory must be
mmapped in the normal way.
> > +static void vfio_pci_dma_buf_release(struct dma_buf *dmabuf)
> > +{
> > + struct vfio_pci_dma_buf *priv = dmabuf->priv;
> > +
> > + /*
> > +* Either this or vfio_pci_dma_buf_cleanup() will remove from the list.
> > +* The refcount prevents both.
> > +*/
> > + if (priv->vdev) {
> > + release_p2p_pages(priv, priv->nr_pages);
> > + kfree(priv->pages);
> > + down_write(>vdev->memory_lock);
> > + list_del_init(>dmabufs_elm);
> > + up_write(>vdev->memory_lock);
>
> Why are we acquiring and releasing the memory_lock write lock
> throughout when we're not modifying the device memory enable state?
> Ugh, we're using it to implicitly lock dmabufs_elm/dmabufs aren't we...
Not really implicitly, but yes the dmabufs list is locked by the
memory_lock.
> > +int vfio_pci_core_feature_dma_buf(struct vfio_pci_core_device *vdev, u32
> > flags,
> > + struct vfio_device_feature_dma_buf __user
> > *arg,
> > + size_t argsz)
> > +{
> > + struct vfio_device_feature_dma_buf get_dma_buf;
> > + struct vfio_region_p2p_area *p2p_areas;
> > + DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
> > + struct vfio_pci_dma_buf *priv;
> > + int i, ret;
> > +
> > + ret = vfio_check_feature(flags, argsz, VFIO_DEVICE_FEATURE_GET,
> > +sizeof(get_dma_buf));
> > + if (ret != 1)
> > + return ret;
> > +
> > + if (copy_from_user(_dma_buf, arg, sizeof(get_dma_buf)))
> > + return -EFAULT;
> > +
> > + p2p_areas = memdup_array_user(>p2p_areas,
> > + get_dma_buf.nr_areas,
> > + sizeof(*p2p_areas));
> > + if (IS_ERR(p2p_areas))
> > + return PTR_ERR(p2p_areas);
> > +
> > + priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> > + if (!priv)
> > + return -ENOMEM;
>
> p2p_areas is leaked.
What is this new p2p_areas thing? It wasn't in my patch..
> > + exp_info.ops = _pci_dmabuf_ops;
> > + exp_info.size = priv->nr_pages << PAGE_SHIFT;
> > + exp_info.flags = get_dma_buf.open_flags;
>
> open_flags from userspace are unchecked.
Huh. That seems to be a dmabuf pattern. :\
> > + exp_info.priv = priv;
> > +
> > + priv->dmabuf = dma_buf_export(_info);
> > + if (IS_ERR(priv->dmabuf)) {
> > + ret = PTR_ERR(priv->dmabuf);
> > + goto err_free_pages;
> > + }
> > +
> > + /* dma_buf_put() now frees priv */
> > + INIT_LIST_HEAD(>dmabufs_elm);
> > + down_write(>memory_lock);
> > + dma_resv_lock(priv->dmabuf->resv, NULL);
> > + priv->revoked = !__vfio_pci_memory_enabled(vdev);
> > + vfio_device_try_get_registration(>vdev);
>
> I guess we're assuming this can't fail in the ioctl path of an open
> device?
Seems like a bug added here.. My version had this as
vfio_device_get(). This stuff has probably changed since I wrote it.
> > + list_add_tail(>dmabufs_elm, >dmabufs);
> > + dma_resv_unlock(priv->dmabuf->resv);
>
> What was the purpose of locking this?
?
> > +void vfio_pci_dma_buf_move(struct vfio_pci_core_device *vdev, bool revoked)
> > +{
> > + struct vfio_pci_dma_buf *priv;
> > + struct vfio_pci_dma_buf *tmp;
> > +
> > + lockdep_assert_held_write(>memory_lock);
> > +
> > + list_for_each_entry_safe(priv, tmp, >dmabufs, dmabufs_elm) {
> > + if (!get_file_rcu(>dmabuf->file))
> > + continue;
>
> Does this indicate the file was closed?
Yes.. The original patch was clearer, Christian asked to open
code it:
+ * Returns true if a reference was successfully obtained. The caller must
+ * interlock with the dmabuf's release function in some way, such as RCU, to
+ * ensure that this is not called on freed memory.
A description of how the locking is working should be put in a comment
above that code.
> > @@ -623,6 +625,8 @@ static int vfio_basic_config_write(struct
> > vfio_pci_core_device *vdev, int pos,
> > *virt_cmd &= cpu_to_le16(~mask);
> > *virt_cmd |= cpu_to_le16(new_cmd & mask);
> >
> > + if (__vfio_pci_memory_enabled(vdev))
> > + vfio_pci_dma_buf_move(vdev, false);
> >
Re: [PATCH v1 2/2] vfio/pci: Allow MMIO regions to be exported through dma-buf
On Sun, 21 Apr 2024 23:30:33 -0700
Vivek Kasireddy wrote:
> From Jason Gunthorpe:
> "dma-buf has become a way to safely acquire a handle to non-struct page
> memory that can still have lifetime controlled by the exporter. Notably
> RDMA can now import dma-buf FDs and build them into MRs which allows for
> PCI P2P operations. Extend this to allow vfio-pci to export MMIO memory
> from PCI device BARs.
>
> The patch design loosely follows the pattern in commit
> db1a8dd916aa ("habanalabs: add support for dma-buf exporter") except this
> does not support pinning.
>
> Instead, this implements what, in the past, we've called a revocable
> attachment using move. In normal situations the attachment is pinned, as a
> BAR does not change physical address. However when the VFIO device is
> closed, or a PCI reset is issued, access to the MMIO memory is revoked.
>
> Revoked means that move occurs, but an attempt to immediately re-map the
> memory will fail. In the reset case a future move will be triggered when
> MMIO access returns. As both close and reset are under userspace control
> it is expected that userspace will suspend use of the dma-buf before doing
> these operations, the revoke is purely for kernel self-defense against a
> hostile userspace."
>
> Following enhancements are made to the original patch:
> - Use P2P DMA APIs to create pages (ZONE_DEVICE) instead of DMA addrs
> - Add a mmap handler to provide CPU access to the dmabuf
> - Add support for creating dmabuf from multiple areas (or ranges)
>
> Original-patch-by: Jason Gunthorpe
> Signed-off-by: Vivek Kasireddy
> ---
> drivers/vfio/pci/Makefile | 1 +
> drivers/vfio/pci/dma_buf.c | 348 +
> drivers/vfio/pci/vfio_pci_config.c | 8 +-
> drivers/vfio/pci/vfio_pci_core.c | 28 ++-
> drivers/vfio/pci/vfio_pci_priv.h | 23 ++
> include/linux/vfio_pci_core.h | 1 +
> include/uapi/linux/vfio.h | 25 +++
> 7 files changed, 426 insertions(+), 8 deletions(-)
> create mode 100644 drivers/vfio/pci/dma_buf.c
>
> diff --git a/drivers/vfio/pci/Makefile b/drivers/vfio/pci/Makefile
> index ce7a61f1d912..b2374856ff62 100644
> --- a/drivers/vfio/pci/Makefile
> +++ b/drivers/vfio/pci/Makefile
> @@ -2,6 +2,7 @@
>
> vfio-pci-core-y := vfio_pci_core.o vfio_pci_intrs.o vfio_pci_rdwr.o
> vfio_pci_config.o
> vfio-pci-core-$(CONFIG_VFIO_PCI_ZDEV_KVM) += vfio_pci_zdev.o
> +vfio-pci-core-$(CONFIG_DMA_SHARED_BUFFER) += dma_buf.o
> obj-$(CONFIG_VFIO_PCI_CORE) += vfio-pci-core.o
>
> vfio-pci-y := vfio_pci.o
> diff --git a/drivers/vfio/pci/dma_buf.c b/drivers/vfio/pci/dma_buf.c
> new file mode 100644
> index ..7bf00fdee69b
> --- /dev/null
> +++ b/drivers/vfio/pci/dma_buf.c
> @@ -0,0 +1,348 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/* Copyright (c) 2022, NVIDIA CORPORATION & AFFILIATES.
> + */
> +#include
> +#include
> +#include
> +
> +#include "vfio_pci_priv.h"
> +
> +MODULE_IMPORT_NS(DMA_BUF);
> +
> +struct vfio_pci_dma_buf {
> + struct dma_buf *dmabuf;
> + struct vfio_pci_core_device *vdev;
> + struct list_head dmabufs_elm;
> + struct page **pages;
> + struct sg_table *sg;
> + unsigned int nr_pages;
> + bool revoked;
> +};
> +
> +static vm_fault_t vfio_pci_dma_buf_fault(struct vm_fault *vmf)
> +{
> + struct vm_area_struct *vma = vmf->vma;
> + struct vfio_pci_dma_buf *priv = vma->vm_private_data;
> + pgoff_t pgoff = vmf->pgoff;
> +
> + if (pgoff >= priv->nr_pages)
> + return VM_FAULT_SIGBUS;
> +
> + return vmf_insert_pfn(vma, vmf->address,
> + page_to_pfn(priv->pages[pgoff]));
> +}
How does this prevent the MMIO space from being mmap'd when disabled at
the device? How is the mmap revoked when the MMIO becomes disabled?
Is it part of the move protocol?
> +
> +static const struct vm_operations_struct vfio_pci_dma_buf_vmops = {
> + .fault = vfio_pci_dma_buf_fault,
> +};
> +
> +static int vfio_pci_dma_buf_mmap(struct dma_buf *dmabuf,
> + struct vm_area_struct *vma)
> +{
> + struct vfio_pci_dma_buf *priv = dmabuf->priv;
> +
> + if ((vma->vm_flags & (VM_SHARED | VM_MAYSHARE)) == 0)
> + return -EINVAL;
> +
> + vma->vm_ops = _pci_dma_buf_vmops;
> + vma->vm_private_data = priv;
> + vm_flags_set(vma, VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP);
> + return 0;
> +}
Does this need to include the new VM_ALLOW_ANY_UNCACHED flag?
> +
> +static int vfio_pci_dma_buf_attach(struct dma_buf *dmabuf,
> +struct dma_buf_attachment *attachment)
> +{
> + struct vfio_pci_dma_buf *priv = dmabuf->priv;
> + int rc;
> +
> + rc = pci_p2pdma_distance_many(priv->vdev->pdev, >dev, 1,
> + true);
> + if (rc < 0)
> + attachment->peer2peer = false;
> + return 0;
> +}
> +
> +static void vfio_pci_dma_buf_unpin(struct dma_buf_attachment *attachment)
> +{
> +}
Re: [PATCH v1 2/2] vfio/pci: Allow MMIO regions to be exported through dma-buf
On 22.04.24 08:30, Vivek Kasireddy wrote:
From Jason Gunthorpe:
"dma-buf has become a way to safely acquire a handle to non-struct page
memory that can still have lifetime controlled by the exporter. Notably
RDMA can now import dma-buf FDs and build them into MRs which allows for
PCI P2P operations. Extend this to allow vfio-pci to export MMIO memory
from PCI device BARs.
The patch design loosely follows the pattern in commit
db1a8dd916aa ("habanalabs: add support for dma-buf exporter") except this
does not support pinning.
Instead, this implements what, in the past, we've called a revocable
attachment using move. In normal situations the attachment is pinned, as a
BAR does not change physical address. However when the VFIO device is
closed, or a PCI reset is issued, access to the MMIO memory is revoked.
Revoked means that move occurs, but an attempt to immediately re-map the
memory will fail. In the reset case a future move will be triggered when
MMIO access returns. As both close and reset are under userspace control
it is expected that userspace will suspend use of the dma-buf before doing
these operations, the revoke is purely for kernel self-defense against a
hostile userspace."
Following enhancements are made to the original patch:
- Use P2P DMA APIs to create pages (ZONE_DEVICE) instead of DMA addrs
- Add a mmap handler to provide CPU access to the dmabuf
- Add support for creating dmabuf from multiple areas (or ranges)
Original-patch-by: Jason Gunthorpe
Signed-off-by: Vivek Kasireddy
---
drivers/vfio/pci/Makefile | 1 +
drivers/vfio/pci/dma_buf.c | 348 +
drivers/vfio/pci/vfio_pci_config.c | 8 +-
drivers/vfio/pci/vfio_pci_core.c | 28 ++-
drivers/vfio/pci/vfio_pci_priv.h | 23 ++
include/linux/vfio_pci_core.h | 1 +
include/uapi/linux/vfio.h | 25 +++
7 files changed, 426 insertions(+), 8 deletions(-)
create mode 100644 drivers/vfio/pci/dma_buf.c
diff --git a/drivers/vfio/pci/Makefile b/drivers/vfio/pci/Makefile
index ce7a61f1d912..b2374856ff62 100644
--- a/drivers/vfio/pci/Makefile
+++ b/drivers/vfio/pci/Makefile
@@ -2,6 +2,7 @@
vfio-pci-core-y := vfio_pci_core.o vfio_pci_intrs.o vfio_pci_rdwr.o vfio_pci_config.o
vfio-pci-core-$(CONFIG_VFIO_PCI_ZDEV_KVM) += vfio_pci_zdev.o
+vfio-pci-core-$(CONFIG_DMA_SHARED_BUFFER) += dma_buf.o
obj-$(CONFIG_VFIO_PCI_CORE) += vfio-pci-core.o
vfio-pci-y := vfio_pci.o
diff --git a/drivers/vfio/pci/dma_buf.c b/drivers/vfio/pci/dma_buf.c
new file mode 100644
index ..7bf00fdee69b
--- /dev/null
+++ b/drivers/vfio/pci/dma_buf.c
@@ -0,0 +1,348 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/* Copyright (c) 2022, NVIDIA CORPORATION & AFFILIATES.
Not sure if this Copyright (c) is 2022 or 2024.
Zhu Yanjun
+ */
+#include
+#include
+#include
+
+#include "vfio_pci_priv.h"
+
+MODULE_IMPORT_NS(DMA_BUF);
+
+struct vfio_pci_dma_buf {
+ struct dma_buf *dmabuf;
+ struct vfio_pci_core_device *vdev;
+ struct list_head dmabufs_elm;
+ struct page **pages;
+ struct sg_table *sg;
+ unsigned int nr_pages;
+ bool revoked;
+};
+
+static vm_fault_t vfio_pci_dma_buf_fault(struct vm_fault *vmf)
+{
+ struct vm_area_struct *vma = vmf->vma;
+ struct vfio_pci_dma_buf *priv = vma->vm_private_data;
+ pgoff_t pgoff = vmf->pgoff;
+
+ if (pgoff >= priv->nr_pages)
+ return VM_FAULT_SIGBUS;
+
+ return vmf_insert_pfn(vma, vmf->address,
+ page_to_pfn(priv->pages[pgoff]));
+}
+
+static const struct vm_operations_struct vfio_pci_dma_buf_vmops = {
+ .fault = vfio_pci_dma_buf_fault,
+};
+
+static int vfio_pci_dma_buf_mmap(struct dma_buf *dmabuf,
+struct vm_area_struct *vma)
+{
+ struct vfio_pci_dma_buf *priv = dmabuf->priv;
+
+ if ((vma->vm_flags & (VM_SHARED | VM_MAYSHARE)) == 0)
+ return -EINVAL;
+
+ vma->vm_ops = _pci_dma_buf_vmops;
+ vma->vm_private_data = priv;
+ vm_flags_set(vma, VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP);
+ return 0;
+}
+
+static int vfio_pci_dma_buf_attach(struct dma_buf *dmabuf,
+ struct dma_buf_attachment *attachment)
+{
+ struct vfio_pci_dma_buf *priv = dmabuf->priv;
+ int rc;
+
+ rc = pci_p2pdma_distance_many(priv->vdev->pdev, >dev, 1,
+ true);
+ if (rc < 0)
+ attachment->peer2peer = false;
+ return 0;
+}
+
+static void vfio_pci_dma_buf_unpin(struct dma_buf_attachment *attachment)
+{
+}
+
+static int vfio_pci_dma_buf_pin(struct dma_buf_attachment *attachment)
+{
+ /*
+* Uses the dynamic interface but must always allow for
+* dma_buf_move_notify() to do revoke
+*/
+ return -EINVAL;
+}
+
+static struct sg_table *
+vfio_pci_dma_buf_map(struct dma_buf_attachment *attachment,
+enum
