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