linux-kernel - Re: [PATCH v5 9/9] vfio/pci: Add dma-buf export support for MMIO regions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALzav=cj_g8ndvbWdm=dukW+37cDh04k1n7ssFrDG+dN3D+cbw@mail.gmail.com>
Date: Mon, 27 Oct 2025 16:13:05 -0700
From: David Matlack <dmatlack@...gle.com>
To: Leon Romanovsky <leon@...nel.org>
Cc: Alex Williamson <alex.williamson@...hat.com>, Leon Romanovsky <leonro@...dia.com>, 
	Jason Gunthorpe <jgg@...dia.com>, Andrew Morton <akpm@...ux-foundation.org>, 
	Bjorn Helgaas <bhelgaas@...gle.com>, Christian König <christian.koenig@....com>, 
	dri-devel@...ts.freedesktop.org, iommu@...ts.linux.dev, 
	Jens Axboe <axboe@...nel.dk>, Joerg Roedel <joro@...tes.org>, kvm@...r.kernel.org, 
	linaro-mm-sig@...ts.linaro.org, linux-block@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-media@...r.kernel.org, linux-mm@...ck.org, 
	linux-pci@...r.kernel.org, Logan Gunthorpe <logang@...tatee.com>, 
	Marek Szyprowski <m.szyprowski@...sung.com>, Robin Murphy <robin.murphy@....com>, 
	Sumit Semwal <sumit.semwal@...aro.org>, Vivek Kasireddy <vivek.kasireddy@...el.com>, 
	Will Deacon <will@...nel.org>
Subject: Re: [PATCH v5 9/9] vfio/pci: Add dma-buf export support for MMIO regions

On Mon, Oct 13, 2025 at 8:44 AM Leon Romanovsky <leon@...nel.org> wrote:
>
> From: Leon Romanovsky <leonro@...dia.com>
>
> Add support for exporting PCI device MMIO regions through dma-buf,
> enabling safe sharing of non-struct page memory with controlled
> lifetime management. This allows RDMA and other subsystems to import
> dma-buf FDs and build them into memory regions for PCI P2P operations.

> +/**
> + * Upon VFIO_DEVICE_FEATURE_GET create a dma_buf fd for the
> + * regions 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.
> + * nr_ranges is the total number of (P2P DMA) ranges that comprise the dmabuf.
> + *
> + * Return: The fd number on success, -1 and errno is set on failure.
> + */
> +#define VFIO_DEVICE_FEATURE_DMA_BUF 11
> +
> +struct vfio_region_dma_range {
> +       __u64 offset;
> +       __u64 length;
> +};
> +
> +struct vfio_device_feature_dma_buf {
> +       __u32   region_index;
> +       __u32   open_flags;
> +       __u32   flags;
> +       __u32   nr_ranges;
> +       struct vfio_region_dma_range dma_ranges[];
> +};

This uAPI would be a good candidate for a VFIO selftest. You can test
that it returns an error when it's supposed to, and a valid fd when
it's supposed to. And once the iommufd importer side is ready, we can
extend the test and verify that the fd can be mapped into iommufd.

It will probably be challenging to meaningfully exercise device P2P
through a selftest, I haven't thought about how to extend the driver
framework for that yet... But you can at least test that all the
ioctls behave like they should.