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

[Fuad Tabba <tabba@google.com>]

Hi Xiaoyao,

On Wed, 16 Jul 2025 at 06:40, Xiaoyao Li <xiaoyao.li@intel.com> wrote:
>
> 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.

You're right. This commit changed a bit, and I should have updated the
commit message.

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

Thanks!
/fuad

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