Public bug reported:

* Summary

Current BF kernel doesn't support VFIO P2P, the following patches need
to backport, based on 6.0 kernel.

1. 
https://patchwork.kernel.org/project/kvm/cover/0-v2-1bd95d72f298+e0e-vfio_pci_priv_...@nvidia.com/
2. 
https://patchwork.kernel.org/project/kvm/cover/0-v2-0f9e632d54fb+d6-vfio_ioctl_split_...@nvidia.com/
3. 
https://patchwork.kernel.org/project/linux-rdma/cover/0-v2-472615b3877e+28f7-vfio_dma_buf_...@nvidia.com/

Due to it's huge dependency, we didn't backport from 1, but instead, we
directly take patch series 3 and fix the code to make it work.

* Setup and Test
1. For ease of testing, we take a BF3 and boot the OS into mmc instead of NVMe 
drive. So leaving NVMe drive free to use.

2. use a test program to verify its correctness.
The program create ibv rdma program, open nvme drive, create dma vfio buf from 
nvme, and let the rdma program read (DMA P2P) the version number of the nvme 
drive.
https://gitlab.com/Mellanox/spdk_team/vfio-dmabuf-test

* UAPI changes
The backport patches are not upstreamed and we have to maintain it if conflict 
in the future.Specifically, the patch "vfio/pci: Allow MMIO regions to be 
exported through dma-buf" adds the following struct and define.
/**
 * 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.
 */
struct vfio_device_feature_dma_buf {
       __u32 region_index;
       __u32 open_flags;
       __u32 offset;
       __u64 length;
};
#define VFIO_DEVICE_FEATURE_DMA_BUF 3

** Affects: linux-bluefield (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-bluefield in Ubuntu.
https://bugs.launchpad.net/bugs/2077887

Title:
  Backport VFIO P2P patch for BlueField 5.15

Status in linux-bluefield package in Ubuntu:
  New

Bug description:
  * Summary

  Current BF kernel doesn't support VFIO P2P, the following patches need
  to backport, based on 6.0 kernel.

  1. 
https://patchwork.kernel.org/project/kvm/cover/0-v2-1bd95d72f298+e0e-vfio_pci_priv_...@nvidia.com/
  2. 
https://patchwork.kernel.org/project/kvm/cover/0-v2-0f9e632d54fb+d6-vfio_ioctl_split_...@nvidia.com/
  3. 
https://patchwork.kernel.org/project/linux-rdma/cover/0-v2-472615b3877e+28f7-vfio_dma_buf_...@nvidia.com/

  Due to it's huge dependency, we didn't backport from 1, but instead,
  we directly take patch series 3 and fix the code to make it work.

  * Setup and Test
  1. For ease of testing, we take a BF3 and boot the OS into mmc instead of 
NVMe drive. So leaving NVMe drive free to use.

  2. use a test program to verify its correctness.
  The program create ibv rdma program, open nvme drive, create dma vfio buf 
from nvme, and let the rdma program read (DMA P2P) the version number of the 
nvme drive.
  https://gitlab.com/Mellanox/spdk_team/vfio-dmabuf-test

  * UAPI changes
  The backport patches are not upstreamed and we have to maintain it if 
conflict in the future.Specifically, the patch "vfio/pci: Allow MMIO regions to 
be exported through dma-buf" adds the following struct and define.
  /**
   * 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.
   */
  struct vfio_device_feature_dma_buf {
         __u32 region_index;
         __u32 open_flags;
         __u32 offset;
         __u64 length;
  };
  #define VFIO_DEVICE_FEATURE_DMA_BUF 3

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/2077887/+subscriptions


-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to     : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to