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

[David Woodhouse]

On Tue, 2026-07-21 at 09:53 -0700, Sean Christopherson wrote:
>  
> > 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.

Normally, the way we'd roll any guest-visible behavioural change out is
to preserve the existing behaviour for existing running guests. So when
we kexec to the new kernel underneath them (or when they resume from
hibernation), they get the old behaviour, and only *new* launches get
the new behaviour. Very much a per-guest thing, not a module option.

Even for things like this where we want it to reach *all* guests in the
end, that gives a relatively controllable rollout of the change — so
*if* we get complaints we can fairly quickly flip the switch so that
new launches *stop* getting the changed behaviour. Then we can think
about per-customer/per-guest opt-in/opt-out (if we really have to).

Very rarely does a module option make sense for us. Systems are largely
immutable at this scale because all else is madness. If a change like
that *is* going to be system-wide and fleet-wide, we'd be more likely
to make a one line code change to set the behaviour we want, and kexec
them all into that version.

But changing visible behaviour underneath millions of running guests
is... not good. I drink enough as it is, thank you very much...

In *this* case though, I do think we can find a middle ground that
works well enough by batching the actual updates up to a threshold.
It's not like the overflow NMI is cycle-accurate anyway; by the time
the guest has *handled* it and read the counter, it's *always* going to
be somewhat past the point at which it actually triggered, surely?

Attachment: smime.p7s
Description: S/MIME cryptographic signature