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?
> 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.
> '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...
> 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"?
If yes, that one has additional properties @hugetlb, @hugetlbsize, and
@seal. Why are they not needed for memory-backend-guest-memfd?
> +
> ``-object iommufd,id=id[,fd=fd]``
> Creates an iommufd backend which allows control of DMA mapping
> through the ``/dev/iommu`` device.
