Re: [PATCH 7/8] qmp: add filtering of statistics by name

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Paolo Bonzini (pbonzini@redhat.com) wrote:
> On 4/27/22 14:01, Dr. David Alan Gilbert wrote:
> > >      "providers": [
> > >        { "provider": "kvm",
> > >          "names": [ "l1d_flush", "exits" ] } } }
> > That looks inconsistent to me; I realise that 'names' has to be a child
> > of providers (since the names are only relevant to a given provider) but
> > how about making the "target" work similarly:
> > 
> > { "execute": "query-stats",
> >    "arguments": {
> >      "target": {
> >        "vcpus": [ "/machine/unattached/device[2]",
> >                   "/machine/unattached/device[4]" ] },
> 
> This would allow queries for different types of targets in a single command,
> but it would be harder for the client to do filtering:
> 
> * with something like "target": { "vcpus": [ array ] }, there is no way for
> the client to say "I want this one statistic, but for all the vCPUs"
> 
> * if target is optional, a client might expect relatively small output from
> today's QEMU, yet suddenly get hundreds of KB from targets other than VMs
> and vCPUs (e.g. block devices including all backing files in the chain, NIC
> backends, etc.).

If I specify a 'vm' it's not obvious to me whether I'd get NICs and
block devices in the future?
Adding a syntax for 'all' into the vcpus list would fix that?

> >      "providers": [
> >         { "provider": "kvm",
> >           "names": [ "l1d_flush", "exits" ] } } }
> > 
> > It's not clear to me whether the "target" should also be specific
> > to a given provider.
> 
> No, the target is a QEMU concept, such as a CPU or a device backend.  It is
> identified by either a QOM path or a unique id.

But doesn't 'kvm' as a provider only make sense for vcpus and VMs; if
you're imagining block devices and other things as targets it would seem
wrong to have that set of providers separate.

Dave

> Paolo
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK