On Mon, 4 Aug 2025 12:39:53 +0200 Mahmoud Adam <mngyadam@xxxxxxxxx> 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
