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

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Feb 24, 2016 at 01:01:34PM +0300, Roman Kagan wrote:
> On Tue, Feb 23, 2016 at 05:49:21PM +0200, Michael S. Tsirkin wrote:
> > On Tue, Feb 23, 2016 at 06:29:33PM +0300, Denis V. Lunev wrote:
> > > On 02/23/2016 06:24 PM, Michael S. Tsirkin wrote:
> > > >On Tue, Feb 23, 2016 at 05:59:44PM +0300, Denis V. Lunev wrote:
> > > >>From: Igor Redko <redkoi@virtuozzo.com>
> > > >>
> > > >>We are making experiments with different autoballooning strategies
> > > >>based on the guest behavior. Thus we need to experiment with different
> > > >>guest statistics. For now every counter change requires QEMU recompilation
> > > >>and dances with Libvirt.
> > > >>
> > > >>This patch introduces transport for unrecognized counters in virtio-balloon.
> > > >>This transport can be used for measuring benefits from using new
> > > >>balloon counters, before submitting any patches. Current alternative
> > > >>is 'guest-exec' transport which isn't made for such delicate matters
> > > >>and can influence test results.
> > > >>
> > > >>Originally all counters with tag >= VIRTIO_BALLOON_S_NR were ignored.
> > > >>Instead of this we keep first (VIRTIO_BALLOON_S_NR + 32) counters from the
> > > >>queue and pass unrecognized ones with the following names: 'x-stat-XXXX',
> > > >>where XXXX is a tag number in hex. Defined counters are reported with their
> > > >>regular names.
> > > >>
> > > >>Signed-off-by: Igor Redko <redkoi@virtuozzo.com>
> > > >>Signed-off-by: Denis V. Lunev <den@openvz.org>
> > > >>CC: Michael S. Tsirkin <mst@redhat.com>
> > > >This seems to open the ABI to abuse.
> > > >Seems like a reasonable way to experiment though.
> > > >How about adding this within #if 0 statements?
> > > >You can uncomment them for debugging ...
> > > I'd prefer to have this enabled.
> > > 
> > > Why do you think that it opens "abuse" way?
> > 
> > Because people will use this to hack drivers and management tools
> > bypassing qemu.
> 
> I'm curious why you think it's a problem?

Because we'll be stuck maintaining them with these x- names.

> Even the existing stats are
> simply propagated to the management level by qemu with no processing
> other than assigning text labels.
>
>  The proposed naming scheme for
> unrecognized counters includes "x-" prefix which explicitly marks them
> as unstable so people using them take their risk.
>
> One of the benefits is forward compatibility, so that counters that have
> graduated into supported ones and have got their own number and name,
> can be made to work with qemu that doesn't yet recognize them.

Then management does start relying on the x- prefixed things,
and once it's used to that it's a slippery slope.

> [ Yes I've seen Den having posted a version hiding this under #ifdef, but I'd
> still be interested to know why the initial proposal wasn't found
> generally useful ]
> 
> Thanks,
> Roman.