On Fri, 17 Feb 2012 10:55:41 -0600 Anthony Liguori <aligu...@us.ibm.com> wrote:
> On 02/08/2012 02:30 PM, Luiz Capitulino wrote: > > This commit adds a QMP API for the guest provided memory statistics > > (long disabled by commit 07b0403dfc2b2ac179ae5b48105096cc2d03375a). > > > > The approach taken by the original commit > > (625a5befc2e3200b396594f002218d235e375da5) was to extend the > > query-balloon command. It introduced a severe bug though: query-balloon > > would hang if the guest didn't respond. > > > > The approach taken by this commit is asynchronous and thus avoids > > any QMP hangs. > > > > First, a client has to issue the balloon-get-memory-stats command. > > That command gets the process started by only sending a request to > > the guest, it doesn't block. When the memory stats are made available > > by the guest, they are returned to the client as an QMP event. > > > > Signed-off-by: Luiz Capitulino<lcapitul...@redhat.com> > > Do we need this to be stable in 1.1? Well, this is disabled for a long time already and libvirt needs it, so I'd say asap, but isn't it possible to implement this with current QOM? > We can do this pretty nicely through QOM. We can have a polling property in > the > virtio-balloon driver, that when set, will enable the virtio-balloon device > to > poll the guest for statistics. > > > We can also have properties for each of the memory statistics and a timestamp > for when the last update was. > > I think this is a friendlier approach for clients, and a cleaner approach > from a > QEMU perspective. I agree it's friendlier, but is it a good idea to keep polling the guest for something that may never be needed by a mngt app (real question)? We could allow the mngt app to do the polling by adding a query-balloon-stats command (instead of balloon-get-memory-stats & event). This command could return the latest available stats if any (with a timestamp) and query the guest for new stats. > > There's nothing generic about this functionality. It's extremely specific to > virtio-balloon. We just lacked ways to expose device specific function > pre-QOM. > > Regards, > > Anthony Liguori >
