Re: [PATCH v2 2/5] KVM: SVM: Always intercept RDMSR for TMCCT (current APIC timer count)

[Naveen N Rao]

On Thu, May 07, 2026 at 11:26:15AM -0700, Sean Christopherson wrote:
> On Thu, May 07, 2026, Sean Christopherson wrote:
> > Oh!  Actually, even better!  This is a great opportunity to dedup Intel vs. AMD
> > (and we can/should do the same for writes).
> 
> Scratch the writes idea, the behavior of Intel x2APIC virtualization and AMD x2AVIC
> are too different.  Intel doesn't trap writes when x2APIC virtualization is
> enabled, and instead redirects the raw value to the APIC backing page.  Which I
> guess makes sense since WRMSR interception is about the same overall cost, and
> it allows the host to safely and fully disable interception for registers it
> doesn't want/need to interpose on.
> 
> AMD on the other hand more or less follows the xAPIC (AVIC) behavior, where regs
> without "fancy" acceleration generate traps.

Sure, your earlier plan to update the readable registers mask is fine.

> 
> Side topic, handling a trap-like unaccelerated AVIC #VMEXIT is ~10 cycles faster
> than handling an intercepted WRMSR (out of ~1770+ cycles for a super simple reg
> like LVT0).  I.e. we _could_ deliberately disable interception of x2AVIC MSRs that
> get trap-like behavior, but for me, being perfectly consistent between Intel and
> AMD is more valuable than shaving a few cycles for paths that should rarely be hit
> (most of the trap-like registers are "configure once and forget about them").
> 
> The only reg that's at all hot is Timer Initial Count Register, and (a) it's a
> moot point with TSC Deadline mode, and (b) the cost to program hrtimers is so high
> than shaving ~10 cycles is completely meaningless.

Thanks for the checking this - this was something I wanted to check. And 
I agree with your assessment. None of those registers look to be 
commonly written to, and ~10 cycles is almost in the noise. If we ever 
come across a performance issue, it should be fairly simple to pass 
additional registers through (with good reason, of course).

On a side note, how did you measure this? My naive attempt showed a lot 
of variation between runs.


- Naveen