Re: [Qemu-devel] [PATCH 4/4] virtio-balloon: keep collecting stats on save/restore

[Ladi Prosek]

On Fri, Aug 19, 2016 at 4:45 PM, Roman Kagan <address@hidden> wrote:
> On Fri, Aug 19, 2016 at 02:08:50PM +0200, Ladi Prosek wrote:
>> On Fri, Aug 19, 2016 at 1:37 PM, Roman Kagan <address@hidden> wrote:
>> > On Fri, Aug 19, 2016 at 11:57:44AM +0200, Ladi Prosek wrote:
>> >> On Thu, Aug 18, 2016 at 8:27 PM, Roman Kagan <address@hidden> wrote:
>> >> > Upon save/restore virtio-balloon stats acquisition stops.  The reason is
>> >> > that the fact that the (only) virtqueue element is being used by QEMU is
>> >> > not recorded anywhere on save, so upon restore it's not released to the
>> >> > guest, making further progress impossible.
>> >> >
>> >> > Saving the information about the used element would introduce 
>> >> > unjustified
>> >> > vmstate incompatibility.
>> >> >
>> >> > So instead just make sure the element is pushed before save, leaving the
>> >> > ball on the guest side.  For that, add vm state change handler to
>> >> > virtio-ballon which would take care of pushing the element if there is
>> >> > one.
>> >>
>> >> Please take a look at:
>> >> https://lists.gnu.org/archive/html/qemu-devel/2016-08/msg01038.html
>> >
>> > Thanks for the pointer, I wish I did a better maillist search before
>> > submitting.
>> >
>> >> virtqueue_discard looks like a better choice than virtqueue_push.
>> >> There's no need to cause churn on the guest side and receive an extra
>> >> set of stats in between the regular timer callbacks.
>> >
>> > I forgot about virtqueue_discard; however, I still tend to slightly
>> > prefer the push version as it IMO makes things easier to follow: the
>> > pumping of stats is always initiated by the guest (both initially on
>> > guest driver load and upon restore), and ->stats_vq_elem being non-NULL
>> > is enough to know that it needs pushing (both in the timer callback and
>> > in vm state change handler).
>>
>> I think I agree, it is nicer this way. virtqueue_discard would add
>> another state of the system (element needs to be popped without first
>> getting notified by the guest) which is not necessary. Thanks!
>
> On a second thought (induced by Stefan's comment), my patch doesn't fix
> the problem for loading the state saved by unfixed QEMU, while yours
> does.

Interesting - I don't think that either patch fixes the issue when
only the loading side is fixed. But your patch handles the opposite
case where only the saving side is fixed, while mine doesn't. With
your patch the state that gets saved is a valid state today (the
timing would have to be right but it is possible to get it with
today's QEMU). With my patch I'm adding a new state that the loading
QEMU must understand, kind of what I alluded to in the previous email.

I hope I'm not missing something. This is where a whiteboard would be handy :)

> So please disregrard this series, and let's move on with yours.
>
> Thanks,
> Roman.