Re: [RFC PATCH 0/9] vfio: Introduce mmap maple tree

[Alex Williamson <alex.williamson@redhat.com>]

On Thu, 14 Aug 2025 11:52:17 +0200
Mahmoud Nagy Adam <mngyadam@amazon.de> wrote:

> The last email was a draft sent by mistake. This is the full version.
> 
> Alex Williamson <alex.williamson@redhat.com> writes:
> 
> > Currently we have a struct vfio_pci_region stored in an array that we
> > dynamically resize for device specific regions and the offset is
> > determined statically from the array index.  We could easily specify an
> > offset and alias field on that object if we wanted to make the address
> > space more compact (without a maple tree) and facilitate multiple
> > regions referencing the same device resource.  This is all just
> > implementation decisions.  We also don't need to support read/write on
> > new regions, we could have them exist advertising only mmap support via
> > REGION_INFO, which simplifies and is consistent with the existing API.
> >  
> 
> What I understand is that you’re proposing an API to create a new
> region.  The user would then fetch a new index and use it with
> REGION_INFO to obtain the pgoff.  This feels like adding another layer
> on top of the pgoff, while the end goal remains the same.
> 
> I'm not sure an alias region offers more value than simply creating an
> alias pgoff.  It may even be more confusing, since—AFAIU—users expect
> indexes to align with PCI BAR indexes in the PCI case.  We would also
> need either a new API or an additional REGION_INFO member to tell the
> user which index the alias refers to and what extra attributes it has.
> 
> Ultimately, both approaches are very similar: one creates a full alias
> region, the other just a pgoff alias, but both would require nearly the
> same internal implementation for pgoff handling.
> 
> The key question is: does a full region alias provide any tangible
> benefits over a pgoff alias?
> 
> In my opinion, it’s clearer to simply have the user call e.g
> REQUEST_REGION_MMAP (which returns a pgoff for mmap) rather than request
> full region creation.

In part this is the argument we've already discussed, creating a new
region and then getting REGION_INFO adds a step for the user, but we
already have REGION_INFO as the standard mechanism for introspection of
regions.  We also have capabilities available as a mechanism within the
REGION_INFO ioctl to describe the mapping flags or region alias
relationship.

If we're this concerned about one additional step for the user, design
the DEVICE_FEATURE ioctl to return both the new region index and the
file offset, the user can ignore the region index if they choose.

To me, regions are just segments of the device fd address space,
regions have a unique offset.  Regions have a vfio-pci specific
convention where a fixed set of region indexes refer to fixed device
resources but never is there a statement in the uAPI that region 0
_uniquely_ indexes BAR 0 and there will never be another region index
mapping this device resource.  The convention exists only to bootstrap
standard device resources.  Adding a mechanism to get a file offset
which is an alias of a region, but not itself reported as a region is
to me, splitting up the device fd address space into two different
allocation methods.

The argument that userspace drivers will get confused if region N
aliases region 0 makes no sense to me.  The user has actively brought
region N into existence knowing in advance that it's addressing the
same device resource as region 0.  Exactly in the same way they'd know
the file offset they get back from REQUEST_REGION_MMAP is an alias to
the requested region.  BUT, since we're invoking a new region, we have
mechanisms to allow persistent introspection of that new region.

The tangible benefit to me is that a new region better aligns with the
existing API and has that introspection/debug'ability aspect, versus
creating an alternate mechanism for making allocations from the device
fd address space.  Thanks,

Alex