Re: [PATCH RFC 02/12] hostmem: Introduce dedicated memory backend for guest_memfd

[Markus Armbruster <armbru@redhat.com>]

Michael Roth <michael.roth@amd.com> 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 <michael.roth@amd.com>

[...]

> 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.