Re: [PATCH v3 10/12] KVM: SEV: Forcefully invalidate SNP VMSA if its backing gmem page is zapped
From: Michael Roth
Date: Wed Jul 01 2026 - 18:54:35 EST
On Tue, Jun 30, 2026 at 03:26:05PM -0700, Sean Christopherson wrote:
> Wire up a gmem_invalid_range() call for SNP VMs, and use it to force vCPUs
> to reload/recheck their guest-provided VMSA if the backing guest_memfd page
> is being invalidated, e.g. is being PUNCH_HOLE'd. Use the same core logic
> to handle invalidations as VMX does for the APIC-access page, as the two
> concepts are nearly identical: shove the physical address of a page into
> the vCPU's control structure:
>
> 1. Snapshot the invalidation sequence counter
> 2. Grab the pfn (from guest_memfd in this case)
> 3. Acquire mmu_lock for read
> 4. Re-request reload if retry is needed, otherwise commit the change.
>
> Note, the re-request action in #4 is necessary as KVM's retry logic is
> fuzzy, i.e. can get false positives. If the guest_memfd page has been
> dropped, at some point a subsequent reload will fail to get a PFN from
> guest_memfd, and KVM will fail KVM_RUN. If the retry was due to a false
> positive, KVM will retry until there are no relevant MMU notifier events
> (and will retry in the "outer" loop, i.e. will drop locks and resched as
> needed).
>
> Note #2! Take care to invalidate the VMSA when a relevant memslot is
> DELETED or MOVED, as invalidations in response to PUNCH_HOLE are predicated
> on memslot bindings (KVM doesn't know what GFN range(s) to invalidate
> without a binding). And more importantly, the VMSA mapping requires a
> memslot, i.e. must be invalidated if its memslots disappears, regardless of
> the state of the underlying guest_memfd inode.
>
> Failure to invalidate the vCPU's control.vmsa_pa (which is checked by
> pre_sev_run()) can prevent KVM from properly freeing the page as firmware
> will reject the RMPUPDATE to reclaim the page with FAIL_INUSE if the vCPU
> is actively running, i.e. if VMSA page is in-use. That in turn leads to an
> RMP #PF on the next use, as the page will still be assigned to the SNP VM.
>
> SEV-SNP: RMPUPDATE failed for PFN 78d198, pg_level: 1, ret: 3
> SEV-SNP: PFN 0x78d198, RMP entry: [0xfff0000000144001 - 0x000000000000000f]
> CPU: 3 UID: 0 PID: 31345 Comm: sev_snp_vmsa_pu Tainted: G U O
> Tainted: [U]=USER, [O]=OOT_MODULE
> Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026
> Call Trace:
> <TASK>
> dump_stack_lvl+0x54/0x70
> rmpupdate+0x12c/0x140
> rmp_make_shared+0x3b/0x60
> sev_gmem_invalidate+0xe0/0x170 [kvm_amd]
> delete_from_page_cache_batch+0x1d8/0x220
> truncate_inode_pages_range+0x120/0x3d0
> kvm_gmem_fallocate+0x19a/0x270 [kvm]
> vfs_fallocate+0x1bc/0x1f0
> __x64_sys_fallocate+0x48/0x70
> do_syscall_64+0x10a/0x480
> entry_SYSCALL_64_after_hwframe+0x4b/0x53
> RIP: 0033:0x496c7e
> </TASK>
> ------------[ cut here ]------------
> SEV: Failed to update RMP entry for PFN 0x78d198 error -14
> WARNING: arch/x86/kvm/svm/sev.c:5160 at sev_gmem_invalidate+0x126/0x170 [kvm_amd], CPU#3: sev_snp_vmsa_pu/31345
> CPU: 3 UID: 0 PID: 31345 Comm: sev_snp_vmsa_pu Tainted: G U O
> Tainted: [U]=USER, [O]=OOT_MODULE
> Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026
> RIP: 0010:sev_gmem_invalidate+0x12b/0x170 [kvm_amd]
> Call Trace:
> <TASK>
> delete_from_page_cache_batch+0x1d8/0x220
> truncate_inode_pages_range+0x120/0x3d0
> kvm_gmem_fallocate+0x19a/0x270 [kvm]
> vfs_fallocate+0x1bc/0x1f0
> __x64_sys_fallocate+0x48/0x70
> do_syscall_64+0x10a/0x480
> entry_SYSCALL_64_after_hwframe+0x4b/0x53
> RIP: 0033:0x496c7e
> </TASK>
> irq event stamp: 20689
> hardirqs last enabled at (20699): [<ffffffff8e76092c>] __console_unlock+0x5c/0x60
> hardirqs last disabled at (20708): [<ffffffff8e760911>] __console_unlock+0x41/0x60
> softirqs last enabled at (20722): [<ffffffff8e6cd74e>] __irq_exit_rcu+0x7e/0x140
> softirqs last disabled at (20717): [<ffffffff8e6cd74e>] __irq_exit_rcu+0x7e/0x140
> ---[ end trace 0000000000000000 ]---
> BUG: unable to handle page fault for address: ffff99a64d198000
> #PF: supervisor write access in kernel mode
> #PF: error_code(0x80000003) - RMP violation
> PGD 13eb001067 P4D 13eb001067 PUD 78d1d1063 PMD 1184e0063 PTE 800000078d198163
> SEV-SNP: PFN 0x78d198, RMP entry: [0x6030000000144001 - 0x000000000000000f]
> Oops: Oops: 0003 [#1] SMP
> CPU: 3 UID: 0 PID: 31407 Comm: highlanderd_hea Tainted: G U W O
> Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE
> Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026
> RIP: 0010:prep_new_page+0x67/0x220
> Call Trace:
> <TASK>
> get_page_from_freelist+0x1c40/0x1c70
> __alloc_frozen_pages_noprof+0xca/0x1f0
> alloc_pages_mpol+0x10b/0x1b0
> alloc_pages_noprof+0x81/0x90
> pte_alloc_one+0x1b/0xd0
> do_pte_missing+0xdf/0x1020
> handle_mm_fault+0x7c7/0xb20
> do_user_addr_fault+0x268/0x6b0
> exc_page_fault+0x67/0xa0
> asm_exc_page_fault+0x26/0x30
> RIP: 0033:0x4a6b1e
> </TASK>
> gsmi: Log Shutdown Reason 0x03
> CR2: ffff99a64d198000
> ---[ end trace 0000000000000000 ]---
> RIP: 0010:prep_new_page+0x67/0x220
>
> Drop the pseudo-TODO comment about needing to pin the page if guest_memfd
> every supports migration, as integrating with invalidations events means
> KVM will Just Work if/when page migration is ever supported (assuming SNP
> hardware supports migrating VMSA pages).
>
> Reported-by: Hyunwoo Kim <imv4bel@xxxxxxxxx>
> Closes: https://lore.kernel.org/all/aimMWzAf5b3luM0b@v4bel
> Fixes: e366f92ea99e ("KVM: SEV: Support SEV-SNP AP Creation NAE event")
> Cc: stable@xxxxxxxxxxxxxxx
> Cc: Tom Lendacky <thomas.lendacky@xxxxxxx>
> Cc: Michael Roth <michael.roth@xxxxxxx>
> Cc: Jörg Rödel <joro@xxxxxxxxxx>
> Cc: Fuad Tabba <tabba@xxxxxxxxxx>
> Cc: Ackerley Tng <ackerleytng@xxxxxxxxxx>
> Signed-off-by: Sean Christopherson <seanjc@xxxxxxxxxx>
Reviewed-by: Michael Roth <michael.roth@xxxxxxx>
Small/optional nit below:
> ---
> arch/x86/include/asm/kvm-x86-ops.h | 2 +
> arch/x86/include/asm/kvm_host.h | 4 ++
> arch/x86/kvm/mmu/mmu.c | 5 ++
> arch/x86/kvm/svm/sev.c | 79 +++++++++++++++++++++++++-----
> arch/x86/kvm/svm/svm.c | 2 +
> arch/x86/kvm/svm/svm.h | 2 +
> arch/x86/kvm/x86.c | 6 +++
> include/linux/kvm_host.h | 1 +
> virt/kvm/guest_memfd.c | 4 ++
> 9 files changed, 94 insertions(+), 11 deletions(-)
>
...
> diff --git a/arch/x86/kvm/svm/svm.h b/arch/x86/kvm/svm/svm.h
> index cf7c1a437f38..123e7bf687ef 100644
> --- a/arch/x86/kvm/svm/svm.h
> +++ b/arch/x86/kvm/svm/svm.h
> @@ -996,6 +996,7 @@ static inline struct page *snp_safe_alloc_page(void)
> {
> return snp_safe_alloc_page_node(numa_node_id(), GFP_KERNEL_ACCOUNT);
> }
> +void sev_snp_reload_vmsa(struct kvm_vcpu *vcpu);
>
> int sev_vcpu_create(struct kvm_vcpu *vcpu);
> void sev_free_vcpu(struct kvm_vcpu *vcpu);
> @@ -1009,6 +1010,7 @@ int sev_dev_get_attr(u32 group, u64 attr, u64 *val);
> extern unsigned int max_sev_asid;
> void sev_handle_rmp_fault(struct kvm_vcpu *vcpu, gpa_t gpa, u64 error_code);
> int sev_gmem_prepare(struct kvm *kvm, kvm_pfn_t pfn, gfn_t gfn, int max_order);
> +void sev_gmem_invalidate_range(struct kvm *kvm, struct kvm_gfn_range *range);
> void sev_gmem_reclaim_memory(kvm_pfn_t start, kvm_pfn_t end);
> int sev_gmem_max_mapping_level(struct kvm *kvm, kvm_pfn_t pfn, bool is_private);
> struct vmcb_save_area *sev_decrypt_vmsa(struct kvm_vcpu *vcpu);
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index bc0c3163f4a3..0bb50997c0e3 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -8170,6 +8170,8 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
> goto out;
> }
> }
> + if (kvm_check_request(KVM_REQ_VMSA_PAGE_RELOAD, vcpu))
> + kvm_x86_call(reload_vmsa)(vcpu);
VMSA is SVM/SEV-specific, and while the event/handling might be SEV-specific,
would it make sense to make the kvm_x86_op generic at least?
'reload_guest_save_area' maybe?
Thanks,
Mike