Re: [PATCH v2 1/5] KVM: SVM: Disable x2AVIC RDMSR interception for MSRs KVM actually supports

[Sean Christopherson]

On Thu, May 07, 2026, Naveen N Rao wrote:
> On Wed, May 06, 2026 at 11:47:42AM -0700, Sean Christopherson wrote:
> > Fix multiple (classes of) bugs with one stone by using KVM's mask of
> > readable local APIC registers to determine which x2APIC MSRs to pass
> > through (or not) when toggling x2AVIC on/off.  The existing hand-coded
> > list of MSRs is wrong on multiple fronts:
> > 
> >  - ARBPRI isn't supported by x2APIC, but its unaccelerated AVIC intercept
> 								  ^^^^^^^^^ 
> 								  access/exit?

Ya, #VMEXIT is a better description here.

> >    is fault-like; disabling interception is nonsensical and suboptimal as
> >    the access generates a #VMEXIT that requires decoding the instruction.
> 
> As far as I can tell, it looks like ARBPRI is actually "supported" in 
> x2APIC mode on AMD processors. APM lists this in the x2APIC register 
> list (Section 16.11.1 x2APIC Register Address Space Table 16-6. x2APIC 
> Register), as well as in the AVIC chapter (15.29.3.1, table 15-22).

Yeah, agreed.  I missed Table 16-6 (so many things to cross-reference, blech).

> This is probably not relevant though, since it looks like KVM has never 
> supported this.

Definitely worth getting it right in the changelog though.

> >  - DFR and ICR2 aren't supported by x2APIC and so don't need their
> >    intercepts disabled for performance reasons.  While the #GP due to
> >    x2APIC being abled has higher priority than the trap-like #VMEXIT,
> 		  ^^^^^ enabled
> 		  
> >    disabling interception of unsupported MSRs is confusing and 
> >    unnecessary.
> > 
> >  - RRR is completely unsupported.
> 
> Would be good to also call out change to EOI and LVTT handling. 

+1.  I either totally missed or forgot that this also impacts LVTT reads, and
I definitely missed that KVM was allowing EOI reads. 

> LVTT reads will now be allowed and should be returned from the backing page.  
> I'm guessing this is fine and that the hardware won't validate it as 
> LVTT may have TSC Deadline enabled (for emulation).

Ya, confirmed via the KUT test:

diff --git x86/apic.c x86/apic.c
index 0a52e9a4..b91e8500 100644
--- x86/apic.c
+++ x86/apic.c
@@ -569,6 +569,9 @@ static inline void apic_change_mode(unsigned long new_mode)
 
        lvtt = apic_read(APIC_LVTT);
        apic_write(APIC_LVTT, (lvtt & ~APIC_LVT_TIMER_MASK) | new_mode);
+
+       lvtt = apic_read(APIC_LVTT);
+       report((lvtt & APIC_LVT_TIMER_MASK) == new_mode, "LVTT mode switch");
 }
 
 static void test_apic_change_mode(void)

And given that AVIC (!x2APIC mode) says that reads are allowed, I don't see how
hardware could do anything differently.