Re: [PATCH 1/8] qmp: Support for querying stats

[Dr. David Alan Gilbert]

* Daniel P. Berrangé (berrange@redhat.com) wrote:
> On Thu, May 05, 2022 at 03:28:23PM +0200, Markus Armbruster wrote:
> > Paolo Bonzini <pbonzini@redhat.com> writes:
> > 
> > > Il 4 maggio 2022 15:22:27 CEST, Markus Armbruster <armbru@redhat.com> ha 
> > > scritto:
> > >>Can you point to existing uses of KVM binary stats introspection data?
> > >
> > > There's none, but Google is using it in house. The same data was 
> > > available before in debugfs and available via the kvm_stat script, so you 
> > > could also refer to Christian Borntraeger's KVM Forum 2019 talk. The 
> > > problems with debugfs are basically that it's only available to root and 
> > > is disabled by secure boot (both issues are not fixable on general 
> > > because they are Linux policy).
> > 
> > I keep bothering you about use cases, because I'm habitually opposed to
> > adding features without credible use cases.
> > 
> > For small features, a bit of plausible hand-waving can suffice, but this
> > one isn't small enough for that.
> > 
> > Plausible hand-waving can sometimes suffice for *experimental* features.
> > Say when the use case can't really materialize without the feature.
> > 
> > Double-checking (pardon my ignorance): we're basically exposing the host
> > kernel's KVM stats via QMP, with the option of extending it to other
> > sources of stats in the future.  Correct?
> > 
> > I think the argument for accepting the interface is basically "if it's
> > good enough for the kernel, it's good enough for us".  Valid point.
> > 
> > This means we'll acquire yet another introspection system, unrelated to
> > the introspection systems we already have in QEMU.
> 
> The second introspection system was the bit I disliked the most.
> 
> The inherant tension we have in that respect is that traditionally
> with QMP we explicitly /want/ the developer to have todo design+coding
> work to expose every new piece of data. Similarly on the client side
> we are expecting work to consume any new piece of data.
> 
> With this command we explicitly do NOT want the developer to do
> any new design+coding work, but instead allow almost arbitrary
> passthrough of whatever data the kernel decides to expose, and
> consumption of arbitrary data without writing new code.

The developer is going to have had to made that design when they put it
in the kernel; they don't really want to repeat the bikeshedding at each
further layer up the stack.  We have to be able to accept that we're
dealing with another (open) interface which has already gone through
review.

Dave

> There is some appeal in why we want todo that, but it is certainly
> a divergance from our historical approach to QMP, so we shouldn't
> make this decision lightly.
> 
> With regards,
> Daniel
> -- 
> |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK