* Paolo Bonzini (pbonz...@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 / dgilb...@redhat.com / Manchester, UK
