Re: [Qemu-devel] [PATCH 6/6] qmp: add balloon-get-memory-stats & event

[Michael Roth]

On Fri, Feb 17, 2012 at 02:07:47PM -0600, Anthony Liguori wrote:
> On 02/17/2012 11:09 AM, Michael Roth wrote:
> >On Fri, Feb 17, 2012 at 10:55:41AM -0600, Anthony Liguori 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<address@hidden>
> >>
> >>Do we need this to be stable in 1.1?
> >>
> >>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.
> >>
> >>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.
> >
> >I'm not so sure, I think proxying guest agent commands through QMP
> >would hit very similar snags, for instance.
> 
> We would proxy guest agent commands as asynchronous QMP commands, no?

Yup, that's the plan. Just mean that the balloon stats fall in the same
bucket and could (eventually) benefit from a more general solution. In
particular, with async QMP in place we could deprecate the polling approach
by having the request do basically what Luiz's patch does and calling
issuing the qmp completion instead of the event.

But I guess the more important question is getting the API right.
Something that allows us to basically turn query-balloon back on would
certainly be optimal... otherwise we'll add new QMP commands and deprecate
them fairly quickly. If avoiding that requires a polling mechanism then it
may be worth it in that sense.

I don't think that requires QOM though, just a stats_pending flags in
virtio-balloon and a periodic timer cb that sends a new request if it's
cleared. QOM might be nicer though.

> 
> Regards,
> 
> Anthony Liguori
> 
> >
> >>
> >>Regards,
> >>
> >>Anthony Liguori
> >>
> >>
> >
> >
>