> >> What if we are not in the just-after-live-migration situation though? > >> If the guest simply didn't add a buffer to the queue for some reason, > >> wouldn't this newly added push/notify break the balloon protocol? > >> > > Could you elaborate how it happens? > > The added code only works for the situation just after live migration. > > right? > > I don't believe so. As eloquently stated in the spec (5.5.6.3 Memory > Statistics), the stats queue is "atypical". If everything goes well, the > stats_vq_elem field is indeed expected to be non-NULL here in > balloon_stats_poll_cb. But it may as well be NULL, for example if step 3. "The > driver collects memory statistics and writes them into a new buffer." takes a > long time and the driver doesn't make it by the time the callback fires. > > Basically, the driver and device play ping-pong and the value of > stats_vq_elem is NULL or non-NULL depending on which side the ball is. > It looks like stats_vq_elem should be part of the QEMU state that is > preserved across migrations, although I'll admit that I am unfamiliar with how
Migrate the stats_vq_elem to destination is better, and it can solve the similar problem I encountered in another patch, I will look into how to do this. Thanks for your explanation! Liang > migrations work and may be missing something important. > > Thanks! > Ladi >
