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

[Jason Gunthorpe <jgg@ziepe.ca>]

On Mon, Aug 04, 2025 at 10:09:44PM +0200, Mahmoud Nagy Adam wrote:
> > We should be able to convert to a maple tree without introducing these
> > "legacy" ops.
> 
> This technically be done directly by changing the current ops (ioctl,
> mmap, read & write) to add vmmap argument in place and call the ops with
> NULL for vmmap entry if the entry not found in the mt

You have gone very far away from my original suggestion:

https://lore.kernel.org/kvm/20250716184028.GA2177603@ziepe.ca/

map2 should not exist, once you introduced a vfio_mmap_ops for free
then the mmap op should be placed into that structure.

ioctl2 is nasty, that should be the "new function op for
VFIO_DEVICE_GET_REGION_INFO" instead. We have been slowly moving
towards the core code doing more decode and dispatch of ioctls instead
of duplicating in drivers.

I still stand by the patch plan I gave in the above email. Clean up
how VFIO_DEVICE_GET_REGION_INFO is handled by drivers and a maple tree
change will trivially drop on top.

The basic way you've used the maple tree here looks plausible, but I'm
still against some VFIO_DEVICE_SET_MMAP_ATTRS as a uapi. mmap cookies
should be immutable, once they are issued they are for a certain thing
and never change.

The entire point of all this infrastructure is to allow more mmap
cookies to be issued. The new UAPI should be some
'VFIO_DEVICE_GET_REGION_INFO2' or whatever that generates an entirely
new mmap cookie with write combining semantics.

Jason