On Mon, Mar 04, 2024, Quentin Perret wrote: > > As discussed in the sub-thread, that might still be required. > > > > One could think about completely forbidding GUP on these mmap'ed > > guest-memfds. But likely, there might be use cases in the future where you > > want to use GUP on shared memory inside a guest_memfd. > > > > (the iouring example I gave might currently not work because > > FOLL_PIN|FOLL_LONGTERM|FOLL_WRITE only works on shmem+hugetlb, and > > guest_memfd will likely not be detected as shmem; 8ac268436e6d contains some > > details) > > Perhaps it would be wise to start with GUP being forbidden if the > current users do not need it (not sure if that is the case in Android, > I'll check) ? We can always relax this constraint later when/if the > use-cases arise, which is obviously much harder to do the other way > around. +1000. At least on the KVM side, I would like to be as conservative as possible when it comes to letting anything other than the guest access guest_memfd.