On Tue, Jun 27, 2023 at 12:52:34PM -0300, Jason Gunthorpe wrote: > On Mon, Jun 26, 2023 at 03:04:21PM -0400, Peter Xu wrote: > > On Mon, Jun 26, 2023 at 03:18:48PM -0300, Jason Gunthorpe wrote: > > > On Mon, Jun 26, 2023 at 08:14:27PM +0200, David Hildenbrand wrote: > > > > > > > So we might have to implement the same page migration as gup does on > > > > FOLL_LONGTERM here ... maybe there are more such cases/drivers that actually > > > > require that handling when simply taking pages out of the memfd, believing > > > > they can hold on to them forever. > > > > > > In general I would like to see an interface to FOLL_LONGTERM pin pages > > > from a memfd. I would quite happily use that in iommufd as well. > > > > > > It solves some problems we have there with fork/exec/etc if the pages > > > are not linked to a mm_struct. > > > > Afaiu any fd based approach should mean it'll never work with private > > memories, while mm-based should be able to work on any kind. > > Is there a significant use case to open a memfd and then use > MAP_PRIVATE? Why would anyone want to do that instead of just using > normal mmap anonymous memory? I remember David Hildenbrand somewhere mentioned the use case where one wants to snapshot a VM RAM into a file, then start multiple instances by loading that VM RAM with MAP_PRIVATE, so it clones a bunch of snapshoted VM running with a single RAM file shared as a template. Not a generic use case, I guess. My question applies not only memfd but also in general - qemu by default doesn't use memfd afaict, so it boils down to e.g. whether you'll target the iommufd project to work in that case, where qemu uses anonymous memory. Privately mapped file memory is only one of those kinds. -- Peter Xu
