From: Jason Gunthorpe <jgg@nvidia.com> To: "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> Cc: 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: [PATCH v2 0/4] Allow MMIO regions to be exported through dma-buf Date: Wed, 31 Aug 2022 20:12:40 -0300 [thread overview] Message-ID: <0-v2-472615b3877e+28f7-vfio_dma_buf_jgg@nvidia.com> (raw) 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. This series supports a use case for SPDK where a NVMe device will be owned by SPDK through VFIO but interacting with a RDMA device. The RDMA device may directly access the NVMe CMB or directly manipulate the NVMe device's doorbell using PCI P2P. However, as a general mechanism, it can support many other scenarios with VFIO. I imagine this dmabuf approach to be usable by iommufd as well for generic and safe P2P mappings. This series goes after the "Break up ioctl dispatch functions to one function per ioctl" series. This is on github: https://github.com/jgunthorpe/linux/commits/vfio_dma_buf v2: - Name the new file dma_buf.c - Restore orig_nents before freeing - Fix reversed logic around priv->revoked - Set priv->index - Rebased on v2 "Break up ioctl dispatch functions" v1: https://lore.kernel.org/r/0-v1-9e6e1739ed95+5fa-vfio_dma_buf_jgg@nvidia.com Cc: linux-rdma@vger.kernel.org Cc: Oded Gabbay <ogabbay@kernel.org> Cc: Christian König <christian.koenig@amd.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Leon Romanovsky <leon@kernel.org> Cc: Maor Gottlieb <maorg@nvidia.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Jason Gunthorpe (4): dma-buf: Add dma_buf_try_get() vfio: Add vfio_device_get() vfio_pci: Do not open code pci_try_reset_function() vfio/pci: Allow MMIO regions to be exported through dma-buf drivers/vfio/pci/Makefile | 1 + drivers/vfio/pci/dma_buf.c | 269 +++++++++++++++++++++++++++++ drivers/vfio/pci/vfio_pci_config.c | 22 ++- drivers/vfio/pci/vfio_pci_core.c | 33 +++- drivers/vfio/pci/vfio_pci_priv.h | 24 +++ drivers/vfio/vfio_main.c | 3 +- include/linux/dma-buf.h | 13 ++ include/linux/vfio.h | 6 + include/linux/vfio_pci_core.h | 1 + include/uapi/linux/vfio.h | 18 ++ 10 files changed, 368 insertions(+), 22 deletions(-) create mode 100644 drivers/vfio/pci/dma_buf.c base-commit: 285fef0ff7f1a97d8acd380971c061985d8dafb5 -- 2.37.2
WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@nvidia.com> To: "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> Cc: linux-rdma@vger.kernel.org, Daniel Vetter <daniel.vetter@ffwll.ch>, Oded Gabbay <ogabbay@kernel.org>, Maor Gottlieb <maorg@nvidia.com>, Leon Romanovsky <leon@kernel.org> Subject: [PATCH v2 0/4] Allow MMIO regions to be exported through dma-buf Date: Wed, 31 Aug 2022 20:12:40 -0300 [thread overview] Message-ID: <0-v2-472615b3877e+28f7-vfio_dma_buf_jgg@nvidia.com> (raw) 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. This series supports a use case for SPDK where a NVMe device will be owned by SPDK through VFIO but interacting with a RDMA device. The RDMA device may directly access the NVMe CMB or directly manipulate the NVMe device's doorbell using PCI P2P. However, as a general mechanism, it can support many other scenarios with VFIO. I imagine this dmabuf approach to be usable by iommufd as well for generic and safe P2P mappings. This series goes after the "Break up ioctl dispatch functions to one function per ioctl" series. This is on github: https://github.com/jgunthorpe/linux/commits/vfio_dma_buf v2: - Name the new file dma_buf.c - Restore orig_nents before freeing - Fix reversed logic around priv->revoked - Set priv->index - Rebased on v2 "Break up ioctl dispatch functions" v1: https://lore.kernel.org/r/0-v1-9e6e1739ed95+5fa-vfio_dma_buf_jgg@nvidia.com Cc: linux-rdma@vger.kernel.org Cc: Oded Gabbay <ogabbay@kernel.org> Cc: Christian König <christian.koenig@amd.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Leon Romanovsky <leon@kernel.org> Cc: Maor Gottlieb <maorg@nvidia.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Jason Gunthorpe (4): dma-buf: Add dma_buf_try_get() vfio: Add vfio_device_get() vfio_pci: Do not open code pci_try_reset_function() vfio/pci: Allow MMIO regions to be exported through dma-buf drivers/vfio/pci/Makefile | 1 + drivers/vfio/pci/dma_buf.c | 269 +++++++++++++++++++++++++++++ drivers/vfio/pci/vfio_pci_config.c | 22 ++- drivers/vfio/pci/vfio_pci_core.c | 33 +++- drivers/vfio/pci/vfio_pci_priv.h | 24 +++ drivers/vfio/vfio_main.c | 3 +- include/linux/dma-buf.h | 13 ++ include/linux/vfio.h | 6 + include/linux/vfio_pci_core.h | 1 + include/uapi/linux/vfio.h | 18 ++ 10 files changed, 368 insertions(+), 22 deletions(-) create mode 100644 drivers/vfio/pci/dma_buf.c base-commit: 285fef0ff7f1a97d8acd380971c061985d8dafb5 -- 2.37.2
next reply other threads:[~2022-08-31 23:13 UTC|newest] Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-08-31 23:12 Jason Gunthorpe [this message] 2022-08-31 23:12 ` [PATCH v2 0/4] Allow MMIO regions to be exported through dma-buf Jason Gunthorpe 2022-08-31 23:12 ` [PATCH v2 1/4] dma-buf: Add dma_buf_try_get() Jason Gunthorpe 2022-08-31 23:12 ` Jason Gunthorpe 2022-09-01 7:55 ` Christian König 2022-09-01 7:55 ` Christian König 2022-09-06 16:44 ` Jason Gunthorpe 2022-09-06 16:44 ` Jason Gunthorpe 2022-09-06 17:52 ` Christian König 2022-09-06 17:52 ` Christian König 2022-08-31 23:12 ` [PATCH v2 2/4] vfio: Add vfio_device_get() Jason Gunthorpe 2022-08-31 23:12 ` Jason Gunthorpe 2022-08-31 23:12 ` [PATCH v2 3/4] vfio_pci: Do not open code pci_try_reset_function() Jason Gunthorpe 2022-08-31 23:12 ` Jason Gunthorpe 2022-08-31 23:12 ` [PATCH v2 4/4] vfio/pci: Allow MMIO regions to be exported through dma-buf Jason Gunthorpe 2022-08-31 23:12 ` Jason Gunthorpe 2022-09-06 9:51 ` Christoph Hellwig 2022-09-06 10:38 ` Christian König 2022-09-06 10:38 ` Christian König 2022-09-06 11:48 ` Jason Gunthorpe 2022-09-06 11:48 ` Jason Gunthorpe 2022-09-06 12:34 ` Oded Gabbay 2022-09-06 12:34 ` Oded Gabbay 2022-09-06 17:59 ` Jason Gunthorpe 2022-09-06 17:59 ` Jason Gunthorpe 2022-09-06 19:44 ` Oded Gabbay 2022-09-06 19:44 ` Oded Gabbay 2022-09-07 12:07 ` Christoph Hellwig 2022-09-07 12:05 ` Christoph Hellwig 2022-09-07 12:33 ` Jason Gunthorpe 2022-09-07 12:33 ` Jason Gunthorpe 2022-09-07 14:29 ` Christoph Hellwig 2022-09-07 14:46 ` Oded Gabbay 2022-09-07 14:46 ` Oded Gabbay 2022-09-07 15:23 ` Jason Gunthorpe 2022-09-07 15:23 ` Jason Gunthorpe 2022-09-07 15:32 ` Christoph Hellwig 2022-09-07 16:12 ` Jason Gunthorpe 2022-09-07 16:12 ` Jason Gunthorpe 2022-09-09 13:24 ` Christoph Hellwig 2022-09-09 14:09 ` Jason Gunthorpe 2022-09-09 14:09 ` Jason Gunthorpe 2022-09-07 16:31 ` Robin Murphy 2022-09-07 16:31 ` Robin Murphy 2022-09-07 16:47 ` Jason Gunthorpe 2022-09-07 16:47 ` Jason Gunthorpe 2022-09-07 17:03 ` Dan Williams 2022-09-07 17:03 ` Dan Williams 2022-09-07 15:01 ` Robin Murphy 2022-09-07 15:01 ` Robin Murphy 2022-09-07 12:03 ` Christoph Hellwig 2022-09-07 15:08 ` Christian König 2022-09-07 15:08 ` Christian König 2022-09-07 15:23 ` Christoph Hellwig
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=0-v2-472615b3877e+28f7-vfio_dma_buf_jgg@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 \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.