Re: [PATCH v2 3/5] KVM: SVM: Only disable x2AVIC WRMSR interception for MSRs that are accelerated

[Sean Christopherson]

On Wed, May 13, 2026, Naveen N Rao wrote:
> On Wed, May 06, 2026 at 11:47:44AM -0700, Sean Christopherson wrote:
> > When x2AVIC is enabled, disable WRMSR interception only for MSRs that are
> > actually accelerated by hardware.  Disabling interception for MSRs that
> > aren't accelerated is functionally "fine", and in some cases a weird "win"
> > for performance, but only for cases that should never be triggered by a
> > well-behaved VM (writes to read-only registers; the #GP will typically
> > occur in the guest without taking a #VMEXIT, even for fault-like exits).
> > 
> > But overall, disabling interception for MSRs that aren't accelerated is at
> > best confusing and unintuitive, and at worst introduces avoidable risk, as
> > the effective guest-visible behavior depends on the whims of the CPU (the
> > behavior of x2APIC MSR writes on at least Zen4 doesn't match the behavior
> > documented in the table in "15.29.3.1 Virtual APIC Register Accesses" of
> > the APM).
> 
> Revisiting this:
> - As far as I can tell, the guest-visible behavior looks to be the same 
>   with/without MSR interception?

Ya, except for a quirks or two, AFAIK the guest-visible behavior is consistent.

>   Did you see different behavior for specific APIC MSRs or across Zen
>   processor families?

AVIC has at least one quirk that is guest visible:

  commit 5a7c7d148e488f43cf9c8e64fa5e1bd715ae0485

    KVM: selftests: Play nice with AMD's AVIC errata
    
    When AVIC, and thus IPI virtualization on AMD, is enabled, the CPU will
    virtualize ICR writes.  Unfortunately, the CPU doesn't do a very good job,
    as it fails to clear the BUSY bit and also allows writing ICR2[23:0],
    despite them being "RESERVED MBZ".  Account for the quirky behavior in
    the xapic_state test to avoid failures in a configuration that likely has
    no hope of ever being enabled in production.

And then there's KVM_X86_QUIRK_LAPIC_MMIO_HOLE, where the guest might see different
values on reads from the vAPIC via MMIO when x2APIC is enabled (I forget exactly
what happens on what platforms; the "hole" (lolz) thing is a mess.  But that's
obviously not related to the MSR intercepts.

And in practice, no real world guest cares for either case.

> - The main difference with x2AVIC looks to be about invalid APIC MSR 
>   accesses generating #GP directly in the guest (but that wouldn't be 
>   guest-visible). I was pointed to this statement in the APM Section 
>   15.29.10 x2AVIC:
> 	x2APIC MSR intercept checks and access checks have higher 
> 	priority than AVIC access permission checks.
> 
> Note the "access checks" qualifier, which covers the #GP seen for 
> invalid MSR accesses.

Yeah, the behavior makes sense, and I'm not surprised it's documented *somehwere*
in the APM, but "Table 15-22. Guest vAPIC Register Access Behavior" really needs
to be updated because it's flat out wrong for x2AVIC.  E.g. either add a separate
column for x2AVIC, or tag/qualify AVIC vs. x2AVIC behavior when they differ.