On Thu, May 28, 2026 at 01:44:39PM +0800, Xiaoyao Li wrote: > On 5/28/2026 8:03 AM, Michael Roth wrote: > > This patchset is also available at: > > > > https://github.com/amdese/qemu/commits/snp-inplace-rfc1 > > > > which is in turn based on the following series: > > > > [PATCH 0/4] "guest_memfd: Fix handling for conversions of MMIO ranges" > > https://lists.gnu.org/archive/html/qemu-devel/2026-05/msg07547.html > > > > > > OVERVIEW > > -------- > > > > This series adds guest_memfd support for in-place conversion of memory > > between private/shared, and enables it for SEV-SNP guests. It is based > > on recently-added kernel support for mmap()-able guest_memfd > > instances[1], which allow it to be used for shared memory, and the > > following patchset[2], which adds additional guest_memfd interfaces to > > allow it to be used to perform in-place conversion: > > > > "[PATCH v7 00/42] guest_memfd: In-place conversion support" > > > > https://lore.kernel.org/kvm/[email protected]/ > > > > That series also introduces a new 'vm_memory_attributes' KVM > > module option, which sets whether memory attributes are tracked > > VM-wide by KVM (vm_memory_attributes=1: the existing 'legacy' mode), > > or per-guest_memfd instance (vm_memory_attributes=0: the new mode > > which allows for in-place conversion). The latter is intended to > > eventually deprecate the legacy mode, at which point in-place > > conversion would become the primarily-supported mode. > > > > > > MOTIVATION > > ---------- > > > > Today, SEV-SNP guests (and other CoCo VM types using guest_memfd) keep > > shared and private memory on separate physical backings: a userspace > > memory-backend object for shared pages, and a kernel-allocated > > guest_memfd file descriptor for private pages. KVM_SET_MEMORY_ATTRIBUTES > > flips which backing the guest sees for a given GPA range, and the old > > backing is typically discarded / hole-punched on conversion to avoid > > doubled memory usage. > > > > That model works, but has a number of downsides that impact certain > > use-cases: > > > > - Each conversion involves discarding pages on one side and faulting > > them in on the other, which incurs allocation overheads in the > > host kernel for every conversion. > > > > - Some use-cases, like pKVM[3], rely on memory isolation rather than > > encryption and rely on in-place conversion to pass through things > > like secured framebuffer memory without needing to bounce data > > through separate shared/private HPAs, which would introduce > > unacceptable latency for that sort of workload. > > > > - Hugetlb support[4] for guest_memfd will rely on it, since things like > > 1GB hugepages with a mix of shared/private sub-ranges would generally > > require 2 1GB hugetlb pages to remain available to handle shared vs. > > private accesses, which quickly causes doubling of guest memory usage. > > > > Recent kernel work[2] makes guest_memfd mmap()-able and lets the *same* > > physical pages be used for both shared and private states for a given > > GPA range, allowing the above pitfalls to be naturally avoided. > > > > This series wires that support up in QEMU. > > + Peter, > > Peter had the series[*] to enable the mmap() of guest memfd and allow it > serve as unencrypted memory for VMs. I believe there are some overlapped > efforts. > > [*] > https://lore.kernel.org/qemu-devel/[email protected]/
Thanks, I wasn't aware of that series but it definitely seems like a good idea to take that for base mmapable guest_memfd support for normal VMs and then rebase my inplace-conversion / confidential VM patches on top. I do think it would be a good idea to introduce a dedicated backend however. I brought up the discussion in that thread, but I think that mostly only calls patch #2 from this series into question and most of the other patches still seem like they'll be needed for confidential VMs. Thanks for pointing this out. -Mike > > > > > DESIGN > > ------ > > > > A new dedicated memory backend, memory-backend-guest-memfd, allocates > > its memory via a guest_memfd file descriptor obtained from KVM with > > the GUEST_MEMFD_FLAG_MMAP | GUEST_MEMFD_FLAG_INIT_SHARED flags. > > A quick feedback: > > The design choice from Peter's series was to extend the current > hostmem-memfd backend to support guest-memfd instead of a new dedicated > backend. > I think we need to evaluate the pros and cons of each other, and make a > choice. > > (I will go read the other part later and provide more feedback)
