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 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.

Conceptually, I am 100% aligned.  My only hesitation/concern is the impact on
the upstream uAPI.  For cases where a new feature (or whatever) is explicitly
enumerated to the guest, I have zero concerns, because any uAPI related to feature
enumeration will need to exist in perpetuity.

But for wonky things like this, where a KVM change is guest visible, but only as
a side effect and not actually enumerated in any way, and for which the goal is
really only to provide roll-out control, I don't like the idea of adding uAPI
*in upstream*.  Because long-term, after many months/years, the change would
become rollback-safe, and thus the need for per-VM control would become obsolete.

In addition to having to carry uAPI (and associated functionality) in perpetuity,
I'm also concerned about having to reach agreement on what exactly is considered
a guest-visible change.  For feature enumeration, outside of trolls, I don't think
anyone seriously thinks it's ok for a kernel upgrade (or rollback) to change what
set of features are enumerated to the guest.

But for side-effects / "microarchitectural" behavioral changes, what's considered
a guest-visible change will vary by use case / provider.  Or rather, what's
considered a big enough change to warrant a per-VM control will vary.  E.g. whether
or not to provide a per-VM control often comes down to balancing overall complexity
versus risk, and that equation will inevitably be different as the total complexity
and risk tolerance will vary by use case.

So I'm very sympathetic to the need to provide per-VM controls for things like
this, but with my upstream hat on, no small part of me thinks that's a problem
that's best handled out-of-tree, by the companies that are running bespoke kernels
anyways and are can feasibly drop such uAPI when it's no longer need.

> 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?