Re: [PATCH 3/9] vfio/pci: Add a helper to create a DMABUF for a BAR-map VMA

[Matt Evans <mattev@meta.com>]

Hi Jason,

On 24/04/2026 19:24, Jason Gunthorpe wrote:
> 
> On Thu, Apr 16, 2026 at 06:17:46AM -0700, Matt Evans wrote:
>> +int vfio_pci_core_mmap_prep_dmabuf(struct vfio_pci_core_device *vdev,
>> +				   struct vm_area_struct *vma,
>> +				   u64 phys_start, u64 req_len,
>> +				   unsigned int res_index)
>> +{
>> +	struct vfio_pci_dma_buf *priv;
>> +	const unsigned int nr_ranges = 1;
>> +	int ret;
>> +
>> +	priv = kzalloc_obj(*priv);
>> +	if (!priv)
>> +		return -ENOMEM;
>> +
>> +	priv->phys_vec = kzalloc_obj(*priv->phys_vec);
>> +	if (!priv->phys_vec) {
>> +		ret = -ENOMEM;
>> +		goto err_free_priv;
>> +	}
>> +
>> +	/*
>> +	 * The mmap() request's vma->vm_offs might be non-zero, but
>> +	 * the DMABUF is created from _offset zero_ of the BAR.  The
>> +	 * portion between zero and the vm_offs is inaccessible
>> +	 * through this VMA, but this approach keeps the
>> +	 * /proc/<pid>/maps offset somewhat consistent with the
>> +	 * pre-DMABUF code.  Size includes the offset portion.
> 
> I'm not sure I understand this comment?
> 
> For the old path vm_pgoff for byte 0 of the bar starts at some large
> offset
> 
> For the new path vm_pgoff for byte 0 of the first range starts at 0

Glad you asked.  :)

This is trying to achieve keeping /proc/<pid>/maps (or similar) somewhat
as informative as pre-DMABUF BAR mmap, in terms of keeping the VMA
vm_offs column useful.  Before this patch, say you mmap() two slices A
and B of the same BAR:

  struct vfio_region_info bar_region;

  vm_a = mmap(0, 0x1000, ..., device_fd, bar_region.offset + 0);
  vm_b = mmap(0, 0x1000, ..., device_fd, bar_region.offset + 0x4000);

...you'd see something like this in /proc/blah/maps:

fffff4000000-fffff4001000 rw-s 10000000000 00:07 148     /dev/vfio/devices/vfio0
fffff5000000-fffff5001000 rw-s 10000004000 00:07 148     /dev/vfio/devices/vfio0

It's nice being able to tell the actual BAR offset (within the
VFIO_PCI_OFFSET_MASK, i.e I _don't_ mean the synthetic region index
offset).

For vm_b, if we create the DMABUF to begin from the start of the
actually-mapped slice

   phys = pci_resource_start(pdev, index) + (vma->vm_pgoff << PAGE_SHIFT)

then the VMA's vm_offs would need to be thunked back down to 0 (since
the fault handler then treats vm_b + 0 as the first byte of the DMABUF).
That works/adds up, but then the vm_offs of both VMAs A & B both have
offset 0, and it's harder to differentiate in /proc/blah/maps.

An example from the later patch "vfio/pci: Provide a user-facing name
for BAR mappings" naming is:

ffffb8070000-ffffbc040000 rw-s 00030000 00:0b 5         /dmabuf:vfio0:0000:00:03.0/1
ffffbc140000-ffffbc240000 rw-s 00000000 00:0b 2         /dmabuf:vfio0:0000:00:03.0/0

We could possibly stash the original offset somewhere and then render it
in the name string, but the name's already about the max size and using
the existing vm_offs column is nicer IMO, doesn't need a new field, etc.

I need to work on this comment then!  What this is trying to say is that
the DMABUF is made artificially larger than the part that is visible
through the VMA.

I.e. the DMABUF starts at the beginning of the BAR and so an mmap for
offset +0x4000 for 0x1000 bytes starts at 0 and the VMA sees
0x4000-0x5000.

>> +	 * This differs from an mmap() of an explicitly-exported
>> +	 * DMABUF which is an arbitrary slice of the BAR, would be
>> +	 * created with the desired offset+size, and would usually be
>> +	 * mmap()ed with pgoff = 0.
>> +	 *
>> +	 * Both are equivalent and vfio_pci_dma_buf_find_pfn() finds
>> +	 * the same PFNs.
>> +	 */
>> +	priv->vdev = vdev;
>> +	priv->nr_ranges = nr_ranges;
>> +	priv->size = (vma->vm_pgoff << PAGE_SHIFT) + req_len;
> 
> And why is size being calculated from pgoff ?

This is the part that makes the size the requested size plus the
invisible portion before the VMA starts (equal to an extra 0x4000 in the
example above, distance from offset 0).


Thanks,


Matt

PS: Thanks also for the other reviews!