Re: [Qemu-devel] [PATCH 1/2] virtio-balloon: export all balloon statistics

[Roman Kagan]

On Thu, Feb 25, 2016 at 12:58:08PM +0100, Markus Armbruster wrote:
> Roman Kagan <address@hidden> writes:
> > On Thu, Feb 25, 2016 at 11:46:59AM +0100, Markus Armbruster wrote:
> >> "Michael S. Tsirkin" <address@hidden> writes:
> >> > On Thu, Feb 25, 2016 at 12:30:21PM +0300, Roman Kagan wrote:
> >> >> The whole point is that there are several participants in the process,
> >> >> with independent release cycles and policies, but with a common
> >> >> "registry" of supported stats (with the master copy being in the kernel,
> >> >> right?).
> >> >
> >> > For most devices it's the virtio spec.
> >> >
> >> >> Once a counter is accepted there, you can start shipping the
> >> >> guest driver providing it, and you don't have to wait until qemu catches
> >> >> up: your management level can read "x-stat-NEW_NUMBER" *or* "new_name",
> >> >> as both NEW_NUMBER and new_name are now allocated for that new counter.
> >> >> 
> >> >> So yes, people are planning to use it, in particluar, before it's merged
> >> >> into qemu proper, but I don't see how that creates any extra maintenance
> >> >> burden on qemu side.  Anybody using x- is on their own; the scheme I
> >> >> sketched seems reasonably safe but is the headache of that management
> >> >> software anyway.
> >> >> 
> >> >> Roman.
> >> >
> >> > Basically if you do this hack QEMU must not reuse the x-stat-NEW_NUMBER
> >> > ever, otherwise management handling it will intepret it
> >> > as legacy QEMU and will break.
> >> 
> >> No, QEMU should aggressively reuse the number part.  Heck, it's free to
> >> randomly mess with it without notice.  Makes the x-stat-N effectively
> >> useless for anything but experimenting.  Which is exactly the point of
> >> naming them x-.
> >
> > I must be missing something...  QEMU has no business with the number at
> > all unless it recognizes it; in that case it only replaces the dumb
> > x-stat-N label with the one it knows.  How can it "randomly mess with
> > it"?
> >
> > Let's get this straight: the only thing QEMU does with balloon stats is
> > marshalling them into json.  (For that matter, libvirt only unmarshalls
> > them back into an array of (int tag, long value) pairs so is similar.)
> > Basically QEMU only plays the role of transport for memory stats between
> > the guest driver and the management layer; I'm not even sure why it has
> > to know what the individual fields mean.  What this patch proposes is
> > essentially to make QEMU not stand in the way of the data it transports;
> > it's only the endpoints' responsibility to agree on the interpretation
> > of the contents.
> 
> If you want to propose a stable interface, don't use the x- prefix.
> That's for unstable stuff.  x- like experimental.

We wanted to remain compatible with the existing query-balloon, which
was already designed with named fields.

Do you think we'd better introduce instead a new monitor command that
would make QEMU just consistently marshall whatever the guest balloon
sent without interpreting, e.g. query-balloon-raw?  Or just drop x- and
declare that all new fields in balloon stats will have stat-N names when
marshalled by QEMU?

Thanks,
Roman.