Re: [PATCH v3 10/12] KVM: SEV: Forcefully invalidate SNP VMSA if its backing gmem page is zapped

[Michael Roth <michael.roth@amd.com>]

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@gmail.com>
> Closes: https://lore.kernel.org/all/aimMWzAf5b3luM0b@v4bel
> Fixes: e366f92ea99e ("KVM: SEV: Support SEV-SNP AP Creation NAE event")
> Cc: stable@vger.kernel.org
> Cc: Tom Lendacky <thomas.lendacky@amd.com>
> Cc: Michael Roth <michael.roth@amd.com>
> Cc: Jörg Rödel <joro@8bytes.org>
> Cc: Fuad Tabba <tabba@google.com>
> Cc: Ackerley Tng <ackerleytng@google.com>
> Signed-off-by: Sean Christopherson <seanjc@google.com>

Reviewed-by: Michael Roth <michael.roth@amd.com>

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