Michael Roth <[email protected]> writes: > On Tue, Jun 02, 2026 at 10:22:01AM +0200, Markus Armbruster wrote: >> Michael Roth <[email protected]> writes: >> >> > In the initial implementation of guest_memfd in the linux kernel, it >> > was not possible to map memory into userspace for direct access; instead >> > the memory provided by the memory backend would be used for cases where >> > a confidential VM wants to access normal/unprotected/unencrypted memory >> > that can be used for shared memory use cases, and for access to private >> > memory a guest_memfd could be associated with the same memslot. A memory >> > 'private' attribute set via KVM_SET_MEMORY_ATTRIBUTES could then be used >> > to have KVM route to the approprate backing memory. >> > >> > In that model, it didn't make sense to introduce a specific backend for >> > guest_memfd, since there was always a generally need to have a separate >> >> a general need? > > Much nicer :) > >> >> > backend type to handle shared memory access/allocation. Instead, QEMU >> > configures the guest_memfd support for the associated memslots >> > internally for cases where it is running a confidential VM. >> > >> > However, with recent changes in guest_memfd kernel support, it is now >> > possible to mmap() a guest_memfd FD into userspace and use it for shared >> > memory, as well as continue to use the same physical pages for the same >> > GPA ranges after they are converted to private ("in-place conversion"). >> > >> > To enable the use of this mmap()-able/guest_memfd-provided memory to be >> > used for normal/shared memory instead of just for private memory, >> > introduce a dedicated guest_memfd memory backend that can be used both >> > for confidential VMs that wish to make use of in-place conversion, as >> > well as for non-confidential VMs that just want to make use of >> > guest_memfd for normal memory (which can be useful both for testing as >> > well as a stepping stone to things like software-protected VMs where the >> > host can be trusted to provided some additional degree of isolation for >> > the VM independently of hardware support). >> > >> > Signed-off-by: Michael Roth <[email protected]> >> >> [...] >> >> > diff --git a/qapi/qom.json b/qapi/qom.json >> > index dd45ac1087..502fafeb15 100644 >> > --- a/qapi/qom.json >> > +++ b/qapi/qom.json >> > @@ -661,7 +661,8 @@ >> > # @share: if false, the memory is private to QEMU; if true, it is >> > # shared (default false for backends memory-backend-file and >> > # memory-backend-ram, true for backends memory-backend-epc, >> > -# memory-backend-memfd, and memory-backend-shm) >> > +# memory-backend-memfd, memory-backend-shm, and >> > +# memory-backend-guest-memfd) >> > # >> > # @reserve: if true, reserve swap space (or huge pages) if applicable >> > # (default: true) (since 6.1) >> > @@ -780,6 +781,18 @@ >> > '*seal': 'bool' }, >> > 'if': 'CONFIG_LINUX' } >> > >> > +## >> > +# @MemoryBackendGuestMemfdProperties: >> > +# >> > +# Properties for memory-backend-guest-memfd objects. >> > +# >> > +# Since: 11.1 >> > +## >> > +{ 'struct': 'MemoryBackendGuestMemfdProperties', >> > + 'base': 'MemoryBackendProperties', >> > + 'data': {}, >> > + 'if': 'CONFIG_LINUX' } >> > + >> >> Identical to MemoryBackendProperties so far. >> >> > ## >> > # @MemoryBackendShmProperties: >> > # >> > @@ -1234,6 +1247,8 @@ >> > 'memory-backend-file', >> > { 'name': 'memory-backend-memfd', >> > 'if': 'CONFIG_LINUX' }, >> > + { 'name': 'memory-backend-guest-memfd', >> > + 'if': 'CONFIG_LINUX' }, >> > 'memory-backend-ram', >> > { 'name': 'memory-backend-shm', >> > 'if': 'CONFIG_POSIX' }, >> > @@ -1312,6 +1327,8 @@ >> > 'memory-backend-file': 'MemoryBackendFileProperties', >> > 'memory-backend-memfd': { 'type': >> > 'MemoryBackendMemfdProperties', >> > 'if': 'CONFIG_LINUX' }, >> > + 'memory-backend-guest-memfd': { 'type': >> > 'MemoryBackendGuestMemfdProperties', >> > + 'if': 'CONFIG_LINUX' }, >> >> You could use MemoryBackendProperties here, and drop >> MemoryBackendGuestMemfdProperties, similar to how memory-backend-ram >> is done. > > That's true. I think I was anticipating it being warranted at some point, but > that doesn't need to happen here. > >> >> > 'memory-backend-ram': 'MemoryBackendProperties', >> > 'memory-backend-shm': { 'type': >> > 'MemoryBackendShmProperties', >> > 'if': 'CONFIG_POSIX' }, >> >> Should we provide guidance on when to use which memory backend? The >> commit message provides some clues... > > Were you thinking from a schema perspective, or something more > user-facing?
The QAPI schema doc comments become the QEMU QMP Reference Manual, which I believe is the first stop for "how do I use this?" Sometimes, a full answer just doesn't fit there comfortably. So we put it elsewhere, and point to it from the QMP Reference. > Either way, docs/system/confidential-guest-support.rst could definitely > use some sprucing up as part of this series, so I can cover this aspect > there as well. > >> >> > diff --git a/qemu-options.hx b/qemu-options.hx >> > index 96ae41f787..3c754c149f 100644 >> > --- a/qemu-options.hx >> > +++ b/qemu-options.hx >> > @@ -5858,6 +5858,11 @@ SRST >> > off will cause a failure during allocation because it is not >> > supported >> > by this backend. >> > >> > + ``-object >> > memory-backend-guest-memfd,id=id,prealloc=on|off,size=size,host-nodes=host-nodes,policy=default|preferred|bind|interleave`` >> > + Creates an anonymous memory file backend object that has similar >> > + semantics to memfd, but is also usable as private memory when >> > + running as a confidential VM. (Linux only) >> >> There is no object type "memfd". Do you mean "memory-backend-memfd"? > > Yes, will update. > >> >> If yes, that one has additional properties @hugetlb, @hugetlbsize, and >> @seal. Why are they not needed for memory-backend-guest-memfd? > > ATM, hugetlb is not enabled for guest_memfd in the kernel. It's likely the > same set of options will apply, but there are also efforts to do things like > plumb DAX memory through guest_memfd for confidential VMs where maybe we end > up needing to be a bit more flexible/creative... not sure, but it seemed > like a good idea to give ourselves a clean slate since the support isn't > there yet anyway. I gather these properties cannot work today. I agree we shouldn't add them until they do. > For seal, I'm not aware of any plan to support that for guest_memfd, so > it seems like unecessary baggage to pull in. Likewise. > Thanks, > > Mike > >> >> > + >> > ``-object iommufd,id=id[,fd=fd]`` >> > Creates an iommufd backend which allows control of DMA mapping >> > through the ``/dev/iommu`` device. >>
