On Tue, Aug 05, 2025 at 05:48:05PM +0200, Mahmoud Nagy Adam wrote: > > Jason Gunthorpe <jgg@xxxxxxxx> writes: > > > map2 should not exist, once you introduced a vfio_mmap_ops for free > > then the mmap op should be placed into that structure. > > Does this mean dropping mmap op completely from vfio ops? Yes, I would aim to that. Once you add the new ops it is much cleaner to have per-vfio_mmaps functions. > but I think also prior of migrating to use packed offsets, we would need > to fix the previous offset calculations, which means read & write ops > also need to access the vmmap object to convert the offset. I imagine you'd do a conversion where the first step is reorganizing the function calls to add a new get_region_info op, while retaining the existing driver assignment of the offsets. Then you'd add the maple tree and continue to use the driver offsets. Record the fixed pgoff ranges in the maple tree. Then I think you'd need to teach read/write to do mt lookups and call out to vfio_mmap_ops read/write functions as well. Now nothing should be relying on the hardwired offsets Finally you could drop the fixed driver assigned offsets and be fully dynamic. > Another question is: since VFIO_DEVICE_GET_REGION_INFO will use mt and > technically will create and return different cookie offset everytime > it's called for the same region, It should not do this. The new infrastructure for a get_region_info op should also take care of de-duplicating the cookies. Jason
