Re: [PATCH v1 0/2] udmabuf: Add back support for mapping hugetlb pages

[Jason Gunthorpe <jgg@nvidia.com>]

On Tue, Jun 27, 2023 at 12:00:38PM -0400, Peter Xu wrote:
> 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.

A file I can see, but a file is not a memfd, we are talking
specifically about memfd, aren't we?

> 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.

I think this may change, as I understand it, the approach for
confidential compute is to put the guest memory in a memfd...

> Privately mapped file memory is only one of those kinds.

I think memfd and related shmem-like objects are a reasonable target. We
already know we should not FOLL_LONGTERM pin file backed pages.

Jason