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

[Markus Armbruster <armbru@redhat.com>]

Roman Kagan <rkagan@virtuozzo.com> writes:

> On Thu, Feb 25, 2016 at 12:58:08PM +0100, Markus Armbruster wrote:
>> Roman Kagan <rkagan@virtuozzo.com> writes:
>> > On Thu, Feb 25, 2016 at 11:46:59AM +0100, Markus Armbruster wrote:
>> >> "Michael S. Tsirkin" <mst@redhat.com> 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?

Now I'm confused.  According to virtio-balloon-stats.txt, they're
exposed as virtio-balloon properties in QOM.  I don't understand how
these are related to query-balloon, nor what a new monitor command
query-balloon-raw would be good for.

You seem to propose adding stats unknown to QEMU with numeric names.  If
there's an authority mapping numbers to meaning, the numbers so mapped
would be suitable as stable interface.  However, for the numbers QEMU
knows to be mapped, it surely knows names, too, so limiting the thing to
such numbers would be pointless.

The only way you can make numbers QEMU doesn't know a stable interface
is declaring the interface a mere transport between guest and management
application.  That's a whole different can of worms.  I have no opinion
whether opening it here is a good idea.