On Wed, May 07, 2025 at 09:39:01AM -0300, Jason Gunthorpe wrote: > On Tue, May 06, 2025 at 12:30:54PM -0700, Nicolin Chen wrote: > > > So, if I understand it correctly, what we want to achieve is to > > have maple tree to manage all PFN ranges. And each range holds > > the same entry, a structure that we can use to verify the sanity > > of an mmap? Let's say for PFNs A->B, the tree should store the > > structure between index A and index B (inclusive)? > > And tell you what has been mmap'd. > > > If this is correct, mtree_alloc_range() that is given a range of > > [0, ULONG_MAX] would allocate the PFN range from the lowest index > > (i.e. 0) instead of PFN A? > > mtree_alloc_range() returns a new range of PFNs that does not overlap > with any existing range. It should always be called on O->U32_MAX (for > 32bit uapi compat) and it should always pick the range to use. Ah, so it's like an address translation table. mtree_alloc_range() just gives us a virtual address range (i.e the cookie) for mmap() to translate back to the real PFN range. I have another question: while I don't think my code is handling this well either, how should we validate the input address is an allowed one? Because mmap() is per ictx, i.e. it's a global translation table. So, the following might happen: let's say we have two vIOMMUs in the same ictx. Either vIOMMU has reported a cookie to index the mtree for the real PFN range: call them PFN_RANGE0 (for vIOMMU0) and PFN_RANGE1 (for vIOMMU1). What if a buggy VMM inverted these cookies between the two vIOMMUs, so it would end up with vIOMMU0 accessing PFN_RANGE1? Thanks Nicolin
