From: Sean Christopherson <seanjc@google.com>
To: Takahiro Itazuri <itazur@amazon.com>
Cc: kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Fuad Tabba <tabba@google.com>,
Brendan Jackman <jackmanb@google.com>,
David Hildenbrand <david@kernel.org>,
David Woodhouse <dwmw2@infradead.org>,
Paul Durrant <pdurrant@amazon.com>,
Nikita Kalyazin <nikita.kalyazin@linux.dev>,
Patrick Roy <patrick.roy@campus.lmu.de>,
Patrick Roy <patrick.roy@linux.dev>,
Derek Manwaring <derekmn@amazon.com>,
Alina Cernea <acernea@amazon.com>,
Michael Zoumboulakis <zoumboul@amazon.com>,
Takahiro Itazuri <zulinx86@gmail.com>
Subject: Re: [RFC PATCH v4 0/7] KVM: pfncache: Add guest_memfd support to pfncache
Date: Tue, 12 May 2026 15:12:50 -0700 [thread overview]
Message-ID: <agOl4nYSFn49saRo@google.com> (raw)
In-Reply-To: <20260420154720.29012-1-itazur@amazon.com>
On Mon, Apr 20, 2026, Takahiro Itazuri wrote:
> [ based on 6.18 with [1] ]
>
> This patch series adds guest_memfd support to gfn_to_pfn_cache (a.k.a.
> pfncache). (This is still labelled RFC since its dependency [1] has not
> yet been merged.)
>
> === Problem Statement ===
>
> pfncache does not work with guest_memfd. pfncaches resolve PFNs via
> hva_to_pfn(), which requires a userspace mapping and relies on GUP.
> This does not work for guest_memfd in the following two ways:
>
> * guest_memfd created without MMAP flag does not have a userspace
> mapping due to the nature of private memory.
Sorry, but NAK. At least until we have a *very* clear and generally agreed-upon
plan for how KVM is going to handle accessing guest memory NO_DIRECT_MAP (my brain
finally caught up to what this series wants to do).
Simply allowing gpcs to tap directly into guest_memfd doesn't allow KVM x86 to
use guest_memfd for non-CoCo VMs. There might be a special class of VMs that can
squeak by, but any VM that finds itself in __kvm_{read,write}_guest_page() or in
FNAME(walk_addr_generic) needs to have guest memory mapped into host userspace.
Predicting what memory a "normal" VM will use for TDP or the source/destination
of emulated MMIO is simply not feasible.
At that point, the "guest_memfd created without MMAP flag" use case is meaningless,
because creating such a guest_memfd instance is *only* useful for backing PRIVATE
memory, which KVM obviously shouldn't be mapping.
This topic was discussed heavily at LPC 2024 (and/or LPC 2023?), and the consensus
was that mapping guest_memfd into host userspace is the least awful choice, the
only complete alternative being a *massive* rework of KVM x86 internals (other
architectures don't suffer as much due to limited emulation).
> KVM: Rename invalidate_begin to invalidate_start for consistencyo
I'll grab this one for 7.2.
> KVM: pfncache: Rename invalidate_start() helper
> KVM: pfncache: Invalidate on gmem invalidation and memattr updates
> KVM: selftests: Test pfncache with gmem-backed memory
> KVM: selftests: Test pfncache invalidation for gmem-backed memory
prev parent reply other threads:[~2026-05-12 22:12 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-20 15:46 [RFC PATCH v4 0/7] KVM: pfncache: Add guest_memfd support to pfncache Takahiro Itazuri
2026-04-20 15:46 ` [RFC PATCH v4 1/7] KVM: pfncache: Resolve PFNs via kvm_gmem_get_pfn() for gmem-backed GPAs Takahiro Itazuri
2026-04-20 15:46 ` [RFC PATCH v4 2/7] KVM: pfncache: Obtain KHVA via vmap() for gmem with NO_DIRECT_MAP Takahiro Itazuri
2026-04-20 15:46 ` [RFC PATCH v4 3/7] KVM: Rename invalidate_begin to invalidate_start for consistency Takahiro Itazuri
2026-04-20 15:46 ` [RFC PATCH v4 4/7] KVM: pfncache: Rename invalidate_start() helper Takahiro Itazuri
2026-05-01 21:38 ` Ackerley Tng
2026-05-12 22:14 ` Sean Christopherson
2026-04-20 15:46 ` [RFC PATCH v4 5/7] KVM: pfncache: Invalidate on gmem invalidation and memattr updates Takahiro Itazuri
2026-05-01 21:43 ` Ackerley Tng
2026-04-20 15:46 ` [RFC PATCH v4 6/7] KVM: selftests: Test pfncache with gmem-backed memory Takahiro Itazuri
2026-05-01 21:16 ` Ackerley Tng
2026-04-20 15:46 ` [RFC PATCH v4 7/7] KVM: selftests: Test pfncache invalidation for " Takahiro Itazuri
2026-05-12 22:12 ` Sean Christopherson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=agOl4nYSFn49saRo@google.com \
--to=seanjc@google.com \
--cc=acernea@amazon.com \
--cc=david@kernel.org \
--cc=derekmn@amazon.com \
--cc=dwmw2@infradead.org \
--cc=itazur@amazon.com \
--cc=jackmanb@google.com \
--cc=kvm@vger.kernel.org \
--cc=nikita.kalyazin@linux.dev \
--cc=patrick.roy@campus.lmu.de \
--cc=patrick.roy@linux.dev \
--cc=pbonzini@redhat.com \
--cc=pdurrant@amazon.com \
--cc=tabba@google.com \
--cc=vkuznets@redhat.com \
--cc=zoumboul@amazon.com \
--cc=zulinx86@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.