[Qemu-devel] Re: [RFD] virtio: Add memory statistics reporting to the balloon driver

[Anthony Liguori <anthony@codemonkey.ws>]

On 01/05/2010 11:08 AM, Adam Litke wrote:
> This patch has been discussed (and ACKed) in the past, but has not yet
> been committed due to the congestion surrounding the 0.12 release and
> other conflicting changes.  I would like to rekindle the discussion so
> that I can make the necessary changes to get this merged.
>
> This patch is ported to 0.12.1 and has one issue that I am aware of:
>
> It still calls monitor_suspend() and monitor_resume() which I understand
> is no longer allowed.  Does anyone have any ideas on how to enable async
> monitor commands?
>
> +static void request_stats(VirtIOBalloon *vb)
> +{
> +    vb->stats_requested = 1;
> +    reset_stats(vb);
> +    monitor_suspend(cur_mon);
>    

This bit is not going to work reliably anymore.  Really, it never worked 
reliably but this is exacerbated with -qmp since a QMP session will 
never be the cur_mon.

We have a couple of options:

1) Introduce a query-balloon command that returns immediately, and 
triggers a request for the guest to update the balloon stats.  When the 
guest does update the balloon stats, trigger an asynchronous message.  
Asynchronous messages are ignored by the human monitor so they would 
never be displayed there which is unfortunate.

2) Make info balloon show the last valid stats and have it request new 
stats.  Stats will always be delayed but it avoids async messages.

3) Make qemu request balloon stats regularly (maybe every 10 seconds) 
and display the latest stats with info balloon.  This avoids the problem 
in #2 but it means that qemu determines the poll rate instead of a 
management tool.

4) Make info-balloon a proper asynchronous command.  We need new 
infrastructure to allow a qmp handler to take a callback that can be 
used to delay the completion of the command.  This addresses all of the 
above problems but it introduces a new one.  Command completion now 
depends on the guest.  This potentially could trip up a naive management 
tool that doesn't realize that the info-balloon command may never complete.

I'm on the fence between 3 and 4 myself.

Regards,

Anthony Liguori