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