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@xxxxxxxxxxx> 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@xxxxxxxxxx/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
