Re: [PATCH 05/10] guestmemfs: add file mmap callback

["Gowans, James" <jgowans@amazon.com>]

On Wed, 2024-10-30 at 15:18 -0700, Frank van der Linden wrote:
> On Tue, Oct 29, 2024 at 4:06 PM Elliot Berman <quic_eberman@quicinc.com> wrote:
> > 
> > On Mon, Aug 05, 2024 at 11:32:40AM +0200, James Gowans wrote:
> > > Make the file data usable to userspace by adding mmap. That's all that
> > > QEMU needs for guest RAM, so that's all be bother implementing for now.
> > > 
> > > When mmaping the file the VMA is marked as PFNMAP to indicate that there
> > > are no struct pages for the memory in this VMA. Remap_pfn_range() is
> > > used to actually populate the page tables. All PTEs are pre-faulted into
> > > the pgtables at mmap time so that the pgtables are usable when this
> > > virtual address range is given to VFIO's MAP_DMA.
> > 
> > Thanks for sending this out! I'm going through the series with the
> > intention to see how it might fit within the existing guest_memfd work
> > for pKVM/CoCo/Gunyah.
> > 
> > It might've been mentioned in the MM alignment session -- you might be
> > interested to join the guest_memfd bi-weekly call to see how we are
> > overlapping [1].
> > 
> > [1]: https://lore.kernel.org/kvm/ae794891-fe69-411a-b82e-6963b594a62a@redhat.com/T/
> > 
> > ---
> > 
> > Was the decision to pre-fault everything because it was convenient to do
> > or otherwise intentionally different from hugetlb?
> > 
> 
> It's memory that is placed outside of of page allocator control, or
> even outside of System RAM - VM_PFNMAP only. So you don't have much of
> a choice..
> 
> In general, for things like guest memory or persistent memory, even if
> struct pages were available, it doesn't seem all that useful to adhere
> to the !MAP_POPULATE standard, why go through any faults to begin
> with?
> 
> For guest_memfd: as I understand it, it's folio-based. And this is
> VM_PFNMAP memory without struct pages / folios. So the main task there
> is probably to teach guest_memfd about VM_PFNMAP memory. That would be
> great, since it then ties in guest_memfd with external guest memory.

Exactly - I think all of the comments on this series are heading in a
similar direction: let's add a custom reserved (PFNMAP) persistent
memory allocator behind guest_memfd and expose that as a filesystem.
This will be what the next version of patch series will do.

JG