On Wed, May 14, 2025 at 04:41:39PM -0700, Ackerley Tng wrote: > Hello, > > This patchset builds upon discussion at LPC 2024 and many guest_memfd > upstream calls to provide 1G page support for guest_memfd by taking > pages from HugeTLB. > > This patchset is based on Linux v6.15-rc6, and requires the mmap support > for guest_memfd patchset (Thanks Fuad!) [1]. > > For ease of testing, this series is also available, stitched together, > at https://github.com/googleprodkernel/linux-cc/tree/gmem-1g-page-support-rfc-v2 Just to record a found issue -- not one that must be fixed. In TDX, the initial memory region is added as private memory during TD's build time, with its initial content copied from source pages in shared memory. The copy operation requires simultaneous access to both shared source memory and private target memory. Therefore, userspace cannot store the initial content in shared memory at the mmap-ed VA of a guest_memfd that performs in-place conversion between shared and private memory. This is because the guest_memfd will first unmap a PFN in shared page tables and then check for any extra refcount held for the shared PFN before converting it to private. Currently, we tested the initial memory region using the in-place conversion version of guest_memfd as backend by modifying QEMU to add an extra anonymous backend to hold the source initial content in shared memory. The extra anonymous backend is freed after finishing ading the initial memory region. This issue is benign for TDX, as the initial memory region can also utilize the traditional guest_memfd, which only allows 4KB mappings. This is acceptable for now, as the initial memory region typically involves a small amount of memory, and we may not enable huge pages for ranges covered by the initial memory region in the near future.
