Re: [PATCH v2 4/5] *** DO NOT MERGE *** KVM: x86: Hack in a stat to track guest-induced exits (for testing)

[Sean Christopherson]

On Fri, May 08, 2026, Naveen N Rao wrote:
> On Wed, May 06, 2026 at 11:47:45AM -0700, Sean Christopherson wrote:
> > Not-signed-off-by: Sean Christopherson <seanjc@xxxxxxxxxx>
> > ---
> >  arch/x86/include/asm/kvm_host.h |  2 +
> >  arch/x86/kvm/svm/svm.c          | 81 +++++++++++++++++++++++++++++++++
> >  arch/x86/kvm/vmx/vmx.c          | 79 ++++++++++++++++++++++++++++++++
> >  arch/x86/kvm/x86.c              |  2 +
> >  4 files changed, 164 insertions(+)
> > 
> > diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> > index c470e40a00aa..bff534bd00dc 100644
> > --- a/arch/x86/include/asm/kvm_host.h
> > +++ b/arch/x86/include/asm/kvm_host.h
> > @@ -1703,6 +1703,8 @@ struct kvm_vcpu_stat {
> >  	u64 invlpg;
> >  
> >  	u64 exits;
> > +	u64 guest_induced_exits;
> > +	u64 msr_exits;
> >  	u64 io_exits;
> >  	u64 mmio_exits;
> >  	u64 signal_exits;
> 
> This looks promising. I'm assuming 'hack' in the title is only meant to 
> indicate the PoC nature of this?

More that I don't think I'll ever propose merging anything like this.

> Taking this forward, introducing a similar bucket for all AVIC/APICv 
> related exits might help with a few tests.

I don't have any plans to take this forward.  guest_induced_exits alone simply
isn't useful enough, even for tests.  Outside of tests, I don't think it has any
usefulness, at all.

For tests and for real-world usage, we really do need per-exit tracking for it
to be useful.  Maybe with some "bundling" allowed for exception vectors?  We can
hack in one-off things like MSR exits, but either we'll have to be super hypocritical
in choosing which use cases are justified and which are not, or we'll have created
a slippery slope by adding a per-exit stat, i.e. we'd just be delaying the inevitable.

For selftests, which is really the only test framework that can utilize stats in
this way, BPF is probably a better answer, at least for the kernel, and probably
for selftests in the long-run as well.  E.g. if we can make it easy-ish to use BPF
in selftests (which is a tall order), then we can write tests that do *very* fancy
validation of KVM behavior, e.g. by peeking at other vCPU state in the context of
each and every exit.