Re: [PATCH v14 08/21] KVM: guest_memfd: Allow host to map guest_memfd pages

[Xiaoyao Li <xiaoyao.li@intel.com>]

On 7/15/2025 5:33 PM, Fuad Tabba wrote:
> Introduce the core infrastructure to enable host userspace to mmap()
> guest_memfd-backed memory. This is needed for several evolving KVM use
> cases:
> 
> * Non-CoCo VM backing: Allows VMMs like Firecracker to run guests
>    entirely backed by guest_memfd, even for non-CoCo VMs [1]. This
>    provides a unified memory management model and simplifies guest memory
>    handling.
> 
> * Direct map removal for enhanced security: This is an important step
>    for direct map removal of guest memory [2]. By allowing host userspace
>    to fault in guest_memfd pages directly, we can avoid maintaining host
>    kernel direct maps of guest memory. This provides additional hardening
>    against Spectre-like transient execution attacks by removing a
>    potential attack surface within the kernel.
> 
> * Future guest_memfd features: This also lays the groundwork for future
>    enhancements to guest_memfd, such as supporting huge pages and
>    enabling in-place sharing of guest memory with the host for CoCo
>    platforms that permit it [3].
> 
> Therefore, enable the basic mmap and fault handling logic within
> guest_memfd. However, this functionality is not yet exposed to userspace
> and remains inactive until two conditions are met in subsequent patches:
> 
> * Kconfig Gate (CONFIG_KVM_GMEM_SUPPORTS_MMAP): A new Kconfig option,
>    KVM_GMEM_SUPPORTS_MMAP, is introduced later in this series. 

Well, KVM_GMEM_SUPPORTS_MMAP is actually introduced by *this* patch, not 
other patches later.

> This
>    option gates the compilation and availability of this mmap
>    functionality at a system level. 

Well, at least from this patch, it doesn't gate the compilation.

> While the code changes in this patch
>    might seem small, the Kconfig option is introduced to explicitly
>    signal the intent to enable this new capability and to provide a clear
>    compile-time switch for it. It also helps ensure that the necessary
>    architecture-specific glue (like kvm_arch_supports_gmem_mmap) is
>    properly defined.
> 
> * Per-instance opt-in (GUEST_MEMFD_FLAG_MMAP): On a per-instance basis,
>    this functionality is enabled by the guest_memfd flag
>    GUEST_MEMFD_FLAG_MMAP, which will be set in the KVM_CREATE_GUEST_MEMFD
>    ioctl. This flag is crucial because when host userspace maps
>    guest_memfd pages, KVM must *not* manage the these memory regions in
>    the same way it does for traditional KVM memory slots. The presence of
>    GUEST_MEMFD_FLAG_MMAP on a guest_memfd instance allows mmap() and
>    faulting of guest_memfd memory to host userspace. Additionally, it
>    informs KVM to always consume guest faults to this memory from
>    guest_memfd, regardless of whether it is a shared or a private fault.
>    This opt-in mechanism ensures compatibility and prevents conflicts
>    with existing KVM memory management. This is a per-guest_memfd flag
>    rather than a per-memslot or per-VM capability because the ability to
>    mmap directly applies to the specific guest_memfd object, regardless
>    of how it might be used within various memory slots or VMs.
> 
> [1] https://github.com/firecracker-microvm/firecracker/tree/feature/secret-hiding
> [2] https://lore.kernel.org/linux-mm/cc1bb8e9bc3e1ab637700a4d3defeec95b55060a.camel@amazon.com
> [3] https://lore.kernel.org/all/c1c9591d-218a-495c-957b-ba356c8f8e09@redhat.com/T/#u
> 
> Reviewed-by: Gavin Shan <gshan@redhat.com>
> Reviewed-by: Shivank Garg <shivankg@amd.com>
> Acked-by: David Hildenbrand <david@redhat.com>
> Co-developed-by: Ackerley Tng <ackerleytng@google.com>
> Signed-off-by: Ackerley Tng <ackerleytng@google.com>
> Signed-off-by: Fuad Tabba <tabba@google.com>
> ---
>   include/linux/kvm_host.h | 13 +++++++
>   include/uapi/linux/kvm.h |  1 +
>   virt/kvm/Kconfig         |  4 +++
>   virt/kvm/guest_memfd.c   | 73 ++++++++++++++++++++++++++++++++++++++++
>   4 files changed, 91 insertions(+)
> 
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index 1ec71648824c..9ac21985f3b5 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -740,6 +740,19 @@ static inline bool kvm_arch_supports_gmem(struct kvm *kvm)
>   }
>   #endif
>   
> +/*
> + * Returns true if this VM supports mmap() in guest_memfd.
> + *
> + * Arch code must define kvm_arch_supports_gmem_mmap if support for guest_memfd
> + * is enabled.

It describes the similar requirement as kvm_arch_has_private_mem and 
kvm_arch_supports_gmem, but it doesn't have the check of

	&& !IS_ENABLED(CONFIG_KVM_GMEM)

So it's straightforward for people to wonder why.

I would suggest just adding the check of !IS_ENABLED(CONFIG_KVM_GMEM) 
like what for kvm_arch_has_private_mem and kvm_arch_supports_gmem. So it 
will get compilation error if any ARCH enables CONFIG_KVM_GMEM without 
defining kvm_arch_supports_gmem_mmap.


> + */
> +#if !defined(kvm_arch_supports_gmem_mmap)
> +static inline bool kvm_arch_supports_gmem_mmap(struct kvm *kvm)
> +{
> +	return false;
> +}
> +#endif
> +