Re: [RFC PATCH 0/2] KVM: pfncache: Support guest_memfd without direct map

[Brendan Jackman <jackmanb@google.com>]

On Wed Dec 3, 2025 at 2:41 PM UTC, Takahiro Itazuri wrote:
> [ based on kvm/next with [1] ]
>
> Recent work on guest_memfd [1] is introducing support for removing guest
> memory from the kernel direct map (Note that this work has not yet been
> merged, which is why this patch series is labelled RFC). The feature is
> useful for non-CoCo VMs to prevent the host kernel from accidentally or
> speculatively accessing guest memory as a general safety improvement.
> Pages for guest_memfd created with GUEST_MEMFD_FLAG_NO_DIRECT_MAP have
> their direct-map PTEs explicitly disabled, and thus cannot rely on the
> direct map.
>
> This breaks the features that use gfn_to_pfn_cache, including kvm-clock.
> gfn_to_pfn_cache caches the pfn and kernel host virtual address (khva)
> for a given gfn so that KVM can repeatedly access the corresponding
> guest page.  The cached khva may later be dereferenced from atomic
> contexts in some cases.  Such contexts cannot tolerate sleep or page
> faults, and therefore cannot use the userspace mapping (uhva), as those
> mappings may fault at any time.  As a result, gfn_to_pfn_cache requires
> a stable, fault-free kernel virtual address for the backing pages,
> independent of the userspace mapping.
>
> This small patch series enables gfn_to_pfn_cache to work correctly when
> a memslot is backed by guest_memfd with GUEST_MEMFD_FLAG_NO_DIRECT_MAP.
> The first patch teaches gfn_to_pfn_cache to obtain pfn for guest_memfd-
> backed memslots via kvm_gmem_get_pfn() instead of GUP (hva_to_pfn()).
> The second patch makes gfn_to_pfn_cache use vmap()/vunmap() to create a
> fault-free kernel address for such pages.  We believe that establishing
> such mapping for paravirtual guest/host communication is acceptable as
> such pages do not contain sensitive data.
>
> Another considered idea was to use memremap() instead of vmap(), since
> gpc_map() already falls back to memremap() if pfn_valid() is false.
> However, vmap() was chosen for the following reason.  memremap() with
> MEMREMAP_WB first attempts to use the direct map via try_ram_remap(),
> and then falls back to arch_memremap_wb(), which explicitly refuses to
> map system RAM.  It would be possible to relax this restriction, but the
> side effects are unclear because memremap() is widely used throughout
> the kernel.  Changing memremap() to support system RAM without the
> direct map solely for gfn_to_pfn_cache feels disproportionate.  If
> additional users appear that need to map system RAM without the direct
> map, revisiting and generalizing memremap() might make sense.  For now,
> vmap()/vunmap() provides a contained and predictable solution.
>
> A possible approach in the future is to use the "ephmap" (or proclocal)
> proposed in [2], but it is not yet clear when that work will be merged.

(Nobody knows how to pronounce "ephmap" aloud and when you do know how
to say it, it sounds like you are sayhing "fmap" which is very
confusing. So next time I post it I plan to call it "mermap" instead:
EPHemeral -> epheMERal).

Apologies for my ignorance of the context here, I may be missing
insights that are obvious, but with that caveat...

The point of the mermap (formerly "ephmap") is to be able to efficiently
map on demand then immediately unmap without the cost of a TLB
shootdown. Is there any reason we'd need to do that here? If we can get
away with a stable vmapping then that seems superior to the mermap
anyway.

Putting it in an mm-local region would be nice (you say there shouldn't
be sensitive data in there, but I guess there's still some potential for
risk? Bounding that to the VMM process seems like a good idea to me)
but that seems nonblocking, could easily be added later. Also note it
doesn't depend on mermap, we could just have an mm-local region of the
vmalloc area. Mermap requires mm-local but not the other-way around.