[libvirt] [PATCHv2 08/11] qemu: bulk stats: implement VCPU group

[Francesco Romani]

----- Original Message -----
> From: "Eric Blake" <eblake at redhat.com>
> To: "Francesco Romani" <fromani at redhat.com>, libvir-list at redhat.com
> Sent: Wednesday, September 3, 2014 1:00:53 AM
> Subject: Re: [libvirt] [PATCHv2 08/11] qemu: bulk stats: implement VCPU group
> 
> On 09/02/2014 06:31 AM, Francesco Romani wrote:
> > This patch implements the VIR_DOMAIN_STATS_VCPU
> > group of statistics.
> > 
> > Signed-off-by: Francesco Romani <fromani at redhat.com>
> > ---
> >  include/libvirt/libvirt.h.in |  1 +
> >  src/libvirt.c                |  8 +++++
> >  src/qemu/qemu_driver.c       | 72
> >  ++++++++++++++++++++++++++++++++++++++++++++
> >  3 files changed, 81 insertions(+)
> > 
> 
> >   *
> > + * VIR_DOMAIN_STATS_VCPU: Return virtual CPU statistics.
> > + * The typed parameter keys are in this format:
> > + * "vcpu.current" - current number of online virtual CPUs
> > + * "vcpu.maximum" - maximum number of online virtual CPUs
> > + * "vcpu.<num>.state" - state of the virtual CPU <num>
> 
> Is this an int mapping to some particular enum?

Yep: virVcpuState. Will document this.

> > + * "vcpu.<num>.time" - virtual cpu time spent by virtual CPU <num>
> > + * "vcpu.<num>.cpu" - physical CPU pinned to virtual CPU <num>
> 
> Missing types.
> 
> Should there be a parameter vcpu.count that says how many vcpu.<num>
> entries to expect?  Or is that vcpu.current?  Or do we have a situation
> where if cpus 0 and 2 are online but 1 and 3 are offline, then we have
> vcpu.0.x and vcpu2.x but not vcpu1.x?

Yes, the latter, due to VCPU hot(un)plugging

> A bit more documentation will help the user deciding which "array"
> entries to expect, and whether the "array" will be sparse if cpus are
> offline.

Will document that the array will be up to "vcpu.maximum" items, could
be sparse and the actual size will be of "vcpu.current" items.

> > +{
> > +    size_t i;
> > +    int ret = -1;
> > +    char param_name[NAME_MAX];
> 
> NAME_MAX (typically 256) is huge, compared to
> VIR_TYPED_PARAM_FIELD_LENGTH (80).

Will switch to VIR_TYPED_PARAM_FIELD_LENGTH here and everywhere I used
NAME_MAX.

Thanks,

-- 
Francesco Romani
RedHat Engineering Virtualization R & D
Phone: 8261328
IRC: fromani