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