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

[Naveen N Rao <naveen@kernel.org>]

On Fri, May 08, 2026 at 10:49:42AM -0700, Sean Christopherson wrote:
> 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@google.com>
> > > ---
> > >  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.

Ack.

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

That's good to hear - tracing was the alternative I had in mind, so it's 
good to know that's an option we can look at. Just hooking into the 
tracepoints should enable a lot of tests to begin with.


Thanks,
Naveen