Re: [RFC PATCH v3 16/27] KVM: SVM: Add handler for VMGEXIT Secure AVIC NAE event

[Sean Christopherson <seanjc@google.com>]

On Wed, Jul 08, 2026, Naveen N Rao (AMD) wrote:
> From: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
> 
> [DO NOT MERGE]
> 
> VMGEXIT Secure AVIC NAE event is used by the guest for two purposes
> determined by VMCB->EXITINFO1:
> 1. SVM_VMGEXIT_SAVIC_REGISTER_GPA: Used to inform the hypervisor about
>    the GPA of the page (RBX) being used as the Secure AVIC backing page.
>    RAX indicates APIC ID of the target vCPU (-1 for self)
> 2. SVM_VMGEXIT_SAVIC_UNREGISTER_GPA: Used to inform the hypervisor that
>    the GPA is no longer being used as the backing page for Secure AVIC.
>    The previously registered GPA for the Secure AVIC backing page is
>    returned by the hypervisor to the guest.
> 
> The primary motivation behind these is to ensure that Secure AVIC
> hardware accesses to the guest APIC backing page never generate an #NPF,
> since Secure AVIC hardware cannot recover from such faults. Quoting the
> APM:
>   "It is required that the guest APIC backing page for a vCPU is
>    pinned in system memory between VMRUN and VMEXIT because some AVIC
>    hardware acceleration sequences may not be restartable when secure
>    AVIC is enabled. If an access to the guest's own backing page by
>    AVIC hardware results in a nested page fault, EXITINFO1 bit 63
>    (Not Restartable) is set (this is an Automatic Exit) and the BUSY
>    bit in the VMSA is set."
> 
> A guest vCPU that has the BUSY bit set in the VMSA cannot be restarted
> and the guest will have to be killed.
> 
> One of the main reasons why the SPTE for a Secure AVIC backing page may
> be invalidated is if it is backed by a huge page in the host, and an
> adjacent page changes state forcing the huge page to be split. Currently
> though, KVM uses guest_memfd to back SEV-SNP guest private memory, and
> those only use 4k pages. As such, this _may_ not be an issue today.
> 
> It is possible that KVM may still invalidate an SPTE for other reasons -
> those will need to be addressed.

As I said in PUCK, this is going to be painful to support, both now and in the
future.  We _could_ get it working, but I'm not at all convinced that I want to
commit to supporting Secure AVIC in its current form.

Though on a slightly happier note, I was wrong about KVM_X86_QUIRK_SLOT_ZAP_ALL.
That quirk only applies to KVM_X86_DEFAULT_VM VMs, i.e. wouldn't need to be
manually disabled for SNP.

And if we go with my suggestion[1] to force KVM_MEMSLOT_GMEM_ONLY when binding to
a gmem instance with in-place conversion enabled, then the fix/optimization to
ignore mmu_notifiers for gmem-only memslots will avoids spurious zaps on that
front[2].

However, there are still problems.  E.g. when converting memory, userspace would
need to make sure to never do a redundant/superfluous KVM_SET_MEMORY_ATTRIBUTES2
on a range that contains a Secure AVIC page, because __kvm_gmem_set_attributes()
will tell the MMU to invalidate SHARED mappings for the entire range.  I.e. by
design, guest_memfd will not chunk the invalidations based on the per-page state
of PRIVATE vs. SHARED, because cross-referencing the current attributes would
incur non-trivial complexity.  For TDX, this isn't a problem because the S-EPT
is a separate paging structure, and so kvm_gfn_range_filter_to_root_types() can
simply skip MIRROR roots to avoid over-zapping PRIVATE memory.  SNP doesn't have
such a thing.

Converting a subset of a huge PRIVATE page would also be problematic, although
that one isn't so bad since we already need to call into the TDP MMU to pre-split
S-EPT pages, because those too can't tolerate spurious zappings.

Those are solvable problems, but I'm not exactly chomping at the bit to take on
the complexity to support what IMO is a poorly designed feature.  There's a very
good reason why control pages are referenced by their host PA in both the VMCS
and VMCB.

TDX's S-EPT obviously has similar restrictions, but with S-EPT the downsides are
a direct tradeoff of the benefits.  Tracking ownership in the page tables to avoid
the complexity and performance costs with an out-of-band table obviously requires
preserving those page tables.  For Secure AVIC, AFAICT it's simply a bad design.

Honestly, this feels a lot like Supervisor Shadow Stacks on Intel, where an EPT
Violation in the middle of a shadow stack access would be destructive to guest
state without a very heavy lift in the hypervisor.  And I'm pretty sure the
feedback to Intel was "provide a better implemetnation" (wait for FRED, maybe?).

[1] https://lore.kernel.org/all/ao7vwx3nMqCjCHZU@google.com
[2] https://lore.kernel.org/kvm/20260615155244.183044-1-alexandru.elisei@arm.com