On Thu, 14 Aug 2025 11:52:17 +0200 Mahmoud Nagy Adam <mngyadam@xxxxxxxxx> wrote: > The last email was a draft sent by mistake. This is the full version. > > Alex Williamson <alex.williamson@xxxxxxxxxx> 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
