Re: [RFC PATCH 0/2] KVM: x86/pmu: Let userspace disable SW accounting of emulated instructions

[Sean Christopherson]

On Tue, Jul 21, 2026, David Woodhouse wrote:
> On Mon, 2026-07-20 at 19:22 +0000, Luka Absandze wrote:
> > On hosts that run guests with an *emulated* vPMU -- guest PMU MSR
> > accesses trap into KVM and each guest counter is backed by a host
> > perf_event -- the per-emulated-instruction PMU accounting added by commit
> > 9cd803d496e7 ("KVM: x86: Update vPMCs when retiring instructions") is
> > pathologically expensive.
> 
> Given that the guest PMU MSR accesses are trapped... is there a reason
> we can't fold a *separate* count of emulated instructions into the
> value we return to the guest?
> 
> I guess the overflow would come late... but isn't that tolerable? 

Like ignoring emulated instructions entirely, it probably depends on the guest.

> And we could probably impose a limit on how large the addend could be — even
> if we only reprogram the PMU once every 100 times, that's still a win?

Hmm, yeah, that'd be better than ignoring emulated instruction entirely, and
would give userspace far better control over how shoddy KVM's emulation is.  Off
the cuff, the change would be fairly trivial too?  E.g.

diff --git arch/x86/kvm/pmu.c arch/x86/kvm/pmu.c
index 7f777049d328..c5f436c6f83f 100644
--- arch/x86/kvm/pmu.c
+++ arch/x86/kvm/pmu.c
@@ -1084,7 +1084,8 @@ static void kvm_pmu_incr_counter(struct kvm_pmc *pmc)
         */
        if (!kvm_vcpu_has_mediated_pmu(vcpu)) {
                pmc->emulated_counter++;
-               kvm_pmu_request_counter_reprogram(pmc);
+               if (pmc->emulated_counter > pmu_something_something_tolerance)
+                       kvm_pmu_request_counter_reprogram(pmc);
                return;
        }