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]/
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)
