From: Ackerley Tng <ackerleytng@google.com>
To: Sean Christopherson <seanjc@google.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Thomas Gleixner <tglx@kernel.org>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Ashish Kalra <ashish.kalra@amd.com>,
Michael Roth <michael.roth@amd.com>,
Brijesh Singh <brijesh.singh@amd.com>,
Marc Zyngier <maz@kernel.org>, Oliver Upton <oupton@kernel.org>,
Joey Gouly <joey.gouly@arm.com>,
Steffen Eiden <seiden@linux.ibm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
David Hildenbrand <david@kernel.org>,
Fuad Tabba <tabba@google.com>, Yan Zhao <yan.y.zhao@intel.com>,
"Edgecombe, Rick P" <rick.p.edgecombe@intel.com>,
Vishal Annapurve <vannapurve@google.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
Ackerley Tng <ackerleytng@google.com>
Subject: [PATCH 0/4] Stop returning struct page from guest_memfd PFN lookup
Date: Tue, 18 Aug 2026 08:12:34 +0000 [thread overview]
Message-ID: <20260818-gmem-no-return-page-v1-0-4f8d939efdbc@google.com> (raw)
KVM currently expects kvm_gmem_get_pfn() to return a refcounted struct
page. Callers (such as x86 TDP MMU, arm64 Stage-2 fault handler, and SEV-SNP
VMSA / RMP handlers) hold this refcount across page fault handling.
Holding a page refcount across fault handling is problematic for guest_memfd.
In-place memory conversions between confidential computing shared and private
states inspect folio refcounts to ensure exclusive ownership by guest_memfd. A
concurrent guest page fault taking a reference on the folio causes conversions
to fail due to an elevated refcount.
guest_memfd already notifies KVM of page invalidations, so users of guest_memfd
within KVM only need to respect the MMU invalidation protocol to safely rely on
guest_memfd to ensure page presence.
This series first prepares the SEV-SNP handlers by treating unassigned RMP
entries as benign races on PSMASH failure (which can occur on concurrent
truncation) and dropping page references early in the RMP fault and VMSA reload
paths. It then updates kvm_gmem_get_pfn() to drop the folio reference internally
and stop returning a struct page pointer across x86 and arm64.
Removing struct page from kvm_gmem_get_pfn() also moves KVM closer toward
supporting memory backends that are not backed by struct page.
I really want in-place conversions to merge in time for 7.4 and so I went
ahead to try this, building off Sean's sample code [1].
The main difference from [1] is that I think sev_handle_rmp_fault()
currently doesn't correctly handle the case where a racing truncation
removed the page from the RMP table. With that fixed, I think
sev_handle_rmp_fault() doesn't need to adopt the MMU invalidation protocol.
I also split the patch up so it's easier to review :)
[1] https://lore.kernel.org/all/an5RJYTwlYeym--O@google.com/
Signed-off-by: Ackerley Tng <ackerleytng@google.com>
---
Ackerley Tng (3):
KVM: SEV: Treat unassigned RMP entry as benign race on PSMASH failure
KVM: SEV: Drop page refcount early during RMP fault handling
KVM: SEV: Drop page refcount early in VMSA reload
Sean Christopherson (1):
KVM: guest_memfd: Stop returning struct page from PFN lookup
arch/arm64/kvm/mmu.c | 4 ++--
arch/arm64/kvm/nested.c | 4 ++--
arch/x86/kvm/mmu/mmu.c | 2 +-
arch/x86/kvm/svm/sev.c | 17 ++++++-----------
include/linux/kvm_host.h | 6 ++----
virt/kvm/guest_memfd.c | 9 ++-------
6 files changed, 15 insertions(+), 27 deletions(-)
---
base-commit: 1b731e5ded480bd1e5546aed35584238661ce72e
change-id: 20260818-gmem-no-return-page-614927a29f97
Best regards,
--
Ackerley Tng <ackerleytng@google.com>
next reply other threads:[~2026-08-18 8:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-18 8:12 Ackerley Tng [this message]
2026-08-18 8:12 ` [PATCH 1/4] KVM: SEV: Treat unassigned RMP entry as benign race on PSMASH failure Ackerley Tng
2026-08-18 8:12 ` [PATCH 2/4] KVM: SEV: Drop page refcount early during RMP fault handling Ackerley Tng
2026-08-18 8:12 ` Yan Zhao
2026-08-18 9:04 ` Ackerley Tng
2026-08-18 8:12 ` [PATCH 3/4] KVM: SEV: Drop page refcount early in VMSA reload Ackerley Tng
2026-08-18 8:12 ` [PATCH 4/4] KVM: guest_memfd: Stop returning struct page from PFN lookup Ackerley Tng
2026-08-18 8:34 ` Yan Zhao
2026-08-18 9:44 ` Ackerley Tng
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=20260818-gmem-no-return-page-v1-0-4f8d939efdbc@google.com \
--to=ackerleytng@google.com \
--cc=ashish.kalra@amd.com \
--cc=bp@alien8.de \
--cc=brijesh.singh@amd.com \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@linux.intel.com \
--cc=david@kernel.org \
--cc=hpa@zytor.com \
--cc=joey.gouly@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=michael.roth@amd.com \
--cc=mingo@redhat.com \
--cc=oupton@kernel.org \
--cc=pbonzini@redhat.com \
--cc=rick.p.edgecombe@intel.com \
--cc=seanjc@google.com \
--cc=seiden@linux.ibm.com \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.com \
--cc=tglx@kernel.org \
--cc=vannapurve@google.com \
--cc=will@kernel.org \
--cc=x86@kernel.org \
--cc=yan.y.zhao@intel.com \
--cc=yuzenghui@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox