Alex Williamson <alex.williamson@xxxxxxxxxx> writes: > > 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? > I think you are mentioning the vfio-pci-core ioctl implementation, as I mentioned in the proposed patch I'm using region insert with mt which is using the same offset calculation for the transitioning period, but this will change to allocating a free region in maple_tree after moving the vfio-pci devices to the new ops and changing the usage of the OFFSET_TO_INDEX macros. I wanted first to move all the vfio-pci devices to the new ops first, then changing the OFFSET_TO_INDEX macro afterwards, to avoid duplicating all the codes that do this calculations which includes page faults code etc.. But so far we are advantaging from per FD range attributes for mmaping, and extra regions can already be used by design. > 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, instead of returning -EINVAL in vfio (vfio-devices could check that themselves). instead of this transitioning stage that this RFC is implementing. I probably need to also update read & write ops to use the vmmap in the same patch as well. Thanks, MNAdam Amazon Web Services Development Center Germany GmbH Tamara-Danz-Str. 13 10243 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B Sitz: Berlin Ust-ID: DE 365 538 597
