Re: [PATCH v4 08/12] hostmem: Support fully shared guest memfd to back a VM

[Peter Xu <peterx@redhat.com>]

On Sun, Aug 23, 2026 at 10:33:36AM -0500, Michael Roth wrote:
> It seemed like the guest_memfd support for directmap removal[1] might be
> a good test for how this all look like once new features start coming
> along for confidential vs. non-confidential so I've been trying to get
> that up and running to see.
> 
> If we keep everything in memory-backend-memfd, there's a little bit
> of awkwardness, but the following schema should cover discoverability of
> QEMU support at least, and then libvirt/management can branch into whatever
> routine is needed for probing actual kernel support:

Isn't that secretmem for generic memfd case? I'm not sure if it'll ever
need to be supported by QEMU at all, but it sounds like exactly that for
normal memfds..

> 
>   diff --git a/qapi/qom.json b/qapi/qom.json
>   index ee981fc44c..4777f09ad1 100644
>   --- a/qapi/qom.json
>   +++ b/qapi/qom.json
>   @@ -774,6 +774,19 @@
>    # @guest-memfd: if true, use guest-memfd to back the memory region.
>    #     (default: false, since: 11.2)
>    #
>   +# @no-directmap: if true, enable support for unmapping backend memory
>   +#                from the kernel directmap to better isolate it from
>   +#                host activity.  This option is only available if a
>   +#                corresponding Features value advertises support for
>   +#                the intended use-case.
>   +#                (default: false, since: 11.2)

Shall we name the property to avoid "no-" prefixes ("kernel-map=on/off",
default on)?  I used "kernel" instead of "direct" because any mmap() from
user can also be described, more or less.. to be direct.

>   +#
>   +# Features:
>   +#
>   +# @no-directmap-for-guest-memfd: If present (and if the hypervisor
>   +# supports the feature), the corresponding option is available if
>   +# @guest-memfd is true.  (since 11.2)
>   +#
>    # Since: 2.12
>    ##
>    { 'struct': 'MemoryBackendMemfdProperties',
>   @@ -781,8 +794,10 @@
>      'data': { '*hugetlb': 'bool',
>                '*hugetlbsize': 'size',
>                '*seal': 'bool',
>   -            '*guest-memfd': 'bool' },
>   -  'if': 'CONFIG_LINUX' }
>   +            '*guest-memfd': 'bool',
>   +           '*no-directmap': 'bool' },
>   +  'if': 'CONFIG_LINUX',

Nitpic: we could drop CONFIG_LINUX IMHO in QAPI if it'll fail properly on
non-linux in impl anyway.

>   +  'features': ['no-directmap-for-guest-memfd'] }
> 
> One notable thing there is the current code only enables it for
> non-confidential VM types, so that's where the KVM_CAP_* checks would
> need to come into play to distinguish between what's supported for
> specific VM types.
> 
> 
> On a side note:
> 
> Ideally we'd be able to do something like the below so we can have one
> 'supported-for-guest-memfd' features that could be associated with
> multiple options, e.g.:
> 
>   +# Features:
>   +#
>   +# @supported-for-guest-memfd: If present (and if the hypervisor
>   +# supports the feature), the corresponding option is available if
>   +# @guest-memfd is true.  (since 11.2)
>   +#
>    # Since: 2.12
>    ##
>    { 'struct': 'MemoryBackendMemfdProperties',
>   @@ -781,7 +794,9 @@
>      'data': { '*hugetlb': 'bool',
>                '*hugetlbsize': 'size',
>                '*seal': 'bool',
>   -            '*guest-memfd': 'bool' },
>   +            '*guest-memfd': 'bool',
>   +            { 'name': 'no-directmap',
>   +              'features': ['supported-for-guest-memfd'] } },
> 
> But it doesn't seem like QAPI is wired up for that. I guess we could add
> that as part of enabling directmap support if it seems useful enough but
> the above should work as well.

Maybe we can still just fail it for normal memfds for now, considering
secretmem or anything like that might still be supported someday.  In
general, for any memfd property (guest-memfd or memfd), if it conceptrally
apply to all (my bet is here..) then IMHO we can keep them around at least
from the interface level, and just fail them when we don't have support for
one of the two.

Thanks,

-- 
Peter Xu