Re: [RFC PATCH 1/2] KVM: x86/pmu: Add CAP to disable SW accounting of emulated instructions

[Sean Christopherson <seanjc@google.com>]

On Tue, Jul 21, 2026, David Woodhouse wrote:
> On Mon, 2026-07-20 at 15:27 -0700, Sean Christopherson wrote:
> > On Mon, Jul 20, 2026, Luka Absandze wrote:
> > > The only functional change for an opted-in VM is reduced accuracy: a
> > > guest counting instructions-retired or branches-retired undercounts by
> > > the instructions KVM emulates in host context, i.e. the behavior that
> > > predates the accounting cited above. Hardware-executed guest
> > > instructions continue to be counted by the backing perf_event, and its
> > > overflow/PMI path is unchanged.
> > 
> > Do you *need* per-VM control, or would a module param (or a magic value for
> > enable_pmu) suffice?  While I mostly buy the "it used to work this way" argument
> > (just "mostly", because that commit landed 4.5 years ago), I'm not exactly keen
> > on adding uAPI that is effectively "re-introduce a bug to workaround fundamental
> > design issues in KVM's emulated PMU implementation".
> 
> Which is the bug? Some would argue that timer interrupts running 50
> times slower is also a bug. We just get to choose *which* bug we want
> the guest to experience :)
> 
> And I think that is a per-guest choice,

Conceptually, I 100% agree.  But in practice, making a per-guest choice requires
a priori knowledge of what the guest is doing and/or what the guest needs/wants.

And so I'm asking, do your use cases have that knowledge *and* will you run VMs
with different requirements on a single host?  Because if you'll end up
configuring all VMs on a given host the same way, then I'd strongly prefer a
module param to give us more flexibility for the future, e.g. if months/years
from now we figure out a way to provide acceptable correctness and efficiency
that would allows us to drop the param entirely.

> if we can't find a way to do it with *sufficient* correctness *and*
> efficiency (qv).