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

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

On Mon, 4 Aug 2025 12:39:53 +0200
Mahmoud Adam <mngyadam@amazon.de> wrote:

> This RFC series proposes the implementation of a new mechanism for
> region mmap attributes using maple trees, based on Jason's suggested
> maple tree and offset cookie approach[0]. The primary motivation is to
> enable userspace applications to specify mmap attributes—such as Write
> Combining (WC)—prior to invoking mmap on a VFIO region. While the
> initial focus is on WC support, this framework can be extended to
> support additional attributes (e.g., cachable) in the future.
> 
> Core concept is: a maple_tree instance is introduced per file
> descriptor within vfio_device_file, allowing per-request ownership and
> control of mmap attributes. Via new VFIO device operations (ioctl &
> mmap), each vfio device populates its maple_tree, primarily during the
> DEVICE_GET_REGION_INFO ioctl. The kernel returns a unique offset key
> to userspace; userspace can then pass this offset to mmap, at which
> point the kernel retrieves the correct maple_tree entry and invokes
> the new mmap op on the vfio device to map the region with the desired
> attributes.
> 
> This model also enables a new UAPI for userspace to set attributes on
> a given mmap offset, allowing flexibility and room for future feature
> expansion.
> 
> Because these changes alter both internal region offset handling and
> the ioctl/mmap interfaces, a staged approach is necessary to manage
> the large scope of the update.
> 
> This RFC implements:
>     - Integration of the maple_tree mechanism and new VFIO ops, along
>       with required helpers.
>     - Initial onboard support for vfio-pci.
>     - Introduction of the new UAPI supporting WC.
> 
> Planned follow-up work:
>     - Extending new ops support to all vfio-pci devices.
>     - Updating usages of VFIO_PCI_OFFSET_TO_INDEX and VFIO_PCI_INDEX_TO_OFFSET.
>     - Migrating additional VFIO devices to the new ops.
>     - Fully removing legacy ioctl and mmap ops, renaming the new ops
>       in their place once migration is complete.
> 
> 
> For now, legacy and new VFIO ops coexist. Legacy ops will be removed
> following full migration across all relevant devices.
> 
> This RFC marks the start of this transition. I am seeking feedback on
> the core implementation to ensure the direction and design are correct
> before proceeding with further conversion and cleanup work. Thank you
> for your review and guidance.

I'm lost.  AIUI, there was a proposal to manage region offsets via a
maple tree, specifically to get a more compact mapping, which I think
is meant to allow new regions (mmap cookies) to be created which are
effectively aliases to other regions with different mapping attributes.

Here we have a partial conversion to a maple tree, but the proposed
ioctl is only specifying a mapping attribute for an existing offset.
How does this require or take advantage of the maple tree?

We should be able to convert to a maple tree without introducing these
"legacy" ops.  Ideally we'd have a compatibility mode where we retain
the existing offsets, but otherwise the maple tree should compact the
region layout within the device fd and be used ubiquitously, mmap and
read/write.  That's only useful though if we decide on a uAPI that
actually wants to allocate ranges of the device fd for use with
alternative mapping attributes.  Thanks,

Alex