All of lore.kernel.org
 help / color / mirror / Atom feed
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: Re: [PATCH 0/4] Allow MMIO regions to be exported through dma-buf
Date: Thu, 18 Aug 2022 09:05:24 -0300	[thread overview]
Message-ID: <Yv4rBEeUMQyIdEzi@nvidia.com> (raw)
In-Reply-To: <0-v1-9e6e1739ed95+5fa-vfio_dma_buf_jgg@nvidia.com>

On Wed, Aug 17, 2022 at 01:11:38PM -0300, Jason Gunthorpe wrote:
> 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
> 
> 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/vfio_pci_config.c  |  22 ++-
>  drivers/vfio/pci/vfio_pci_core.c    |  33 +++-
>  drivers/vfio/pci/vfio_pci_dma_buf.c | 265 ++++++++++++++++++++++++++++

I forget about this..

Alex, do you want to start doing as Linus discused and I will rename
this new file to "dma_buf.c" ?

Or keep this directory as having the vfio_pci_* prefix for
consistency?

Jason

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: Re: [PATCH 0/4] Allow MMIO regions to be exported through dma-buf
Date: Thu, 18 Aug 2022 09:05:24 -0300	[thread overview]
Message-ID: <Yv4rBEeUMQyIdEzi@nvidia.com> (raw)
In-Reply-To: <0-v1-9e6e1739ed95+5fa-vfio_dma_buf_jgg@nvidia.com>

On Wed, Aug 17, 2022 at 01:11:38PM -0300, Jason Gunthorpe wrote:
> 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
> 
> 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/vfio_pci_config.c  |  22 ++-
>  drivers/vfio/pci/vfio_pci_core.c    |  33 +++-
>  drivers/vfio/pci/vfio_pci_dma_buf.c | 265 ++++++++++++++++++++++++++++

I forget about this..

Alex, do you want to start doing as Linus discused and I will rename
this new file to "dma_buf.c" ?

Or keep this directory as having the vfio_pci_* prefix for
consistency?

Jason

  parent reply	other threads:[~2022-08-18 12:05 UTC|newest]

Thread overview: 40+ 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 ` Jason Gunthorpe
2022-08-17 16:11 ` [PATCH 1/4] dma-buf: Add dma_buf_try_get() Jason Gunthorpe
2022-08-17 16:11   ` Jason Gunthorpe
2022-08-17 16:11 ` [PATCH 2/4] vfio: Add vfio_device_get() Jason Gunthorpe
2022-08-17 16:11   ` 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   ` 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-17 16:11   ` Jason Gunthorpe
2022-08-21 13:51   ` Fwd: " Oded Gabbay
2022-08-21 13:51     ` Oded Gabbay
2022-08-26 18:10     ` Jason Gunthorpe
2022-08-26 18:10       ` Jason Gunthorpe
2022-08-29  5:04   ` Yan Zhao
2022-08-29  5:04     ` Yan Zhao
2022-08-29 12:26     ` Jason Gunthorpe
2022-08-29 12:26       ` Jason Gunthorpe
2022-08-18 11:07 ` [PATCH 0/4] " Christian König
2022-08-18 11:07   ` Christian König
2022-08-18 12:03   ` Jason Gunthorpe
2022-08-18 12:03     ` Jason Gunthorpe
2022-08-18 12:58     ` Christian König
2022-08-18 12:58       ` Christian König
2022-08-18 13:16       ` Jason Gunthorpe
2022-08-18 13:16         ` Jason Gunthorpe
2022-08-18 13:37         ` Christian König
2022-08-18 13:37           ` Christian König
2022-08-19 13:11           ` Jason Gunthorpe
2022-08-19 13:11             ` Jason Gunthorpe
2022-08-19 13:33             ` Christian König
2022-08-19 13:33               ` Christian König
2022-08-19 13:39               ` Jason Gunthorpe
2022-08-19 13:39                 ` Jason Gunthorpe
2022-08-19 13:47                 ` Christian König
2022-08-19 13:47                   ` Christian König
2022-08-18 12:05 ` Jason Gunthorpe [this message]
2022-08-18 12:05   ` Jason Gunthorpe
2022-08-22 21:58   ` Alex Williamson
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=Yv4rBEeUMQyIdEzi@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: link
Be 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.