> From: Paolo Bonzini [mailto:pbonz...@redhat.com] > On 04/05/2017 14:34, Pavel Dovgalyuk wrote: > >> From: Paolo Bonzini [mailto:pbonz...@redhat.com] > >> On 04/05/2017 14:10, Pavel Dovgalyuk wrote: > >>>> From: Paolo Bonzini [mailto:pbonz...@redhat.com] > >>>> On 04/05/2017 13:54, Pavel Dovgalyuk wrote: > >>>>>> From: Paolo Bonzini [mailto:pbonz...@redhat.com] > >>>>>> On 04/05/2017 13:13, Pavel Dovgalyuk wrote: > >>>>>>>>> This patch does not allows saving/loading vmstate when > >>>>>>>>> replay events queue is not empty. There is no reliable > >>>>>>>>> way to save events queue, because it describes internal > >>>>>>>>> coroutine state. Therefore saving and loading operations > >>>>>>>>> should be deferred to another record/replay step. > >>>>>>>> > >>>>>>>> Can it actually be non-empty after bdrv_drain_all? > >>>>>>> > >>>>>>> drain/flush cannot succeed, because started requests are > >>>>>>> prisoned in the replay events queue. > >>>>>> > >>>>>> But that would apply to loading only. Saving should still be always > >>>>>> possible. > >>>>> > >>>>> We can save it. But it wouldn't load correctly - replay queue will be > >>>>> empty after > loading. > >>>> > >>>> When saving you can drain, and then the events queue should be empty. > >>>> Or I am misunderstanding how it works, which is possible too. > >>> > >>> Drain will wait until the queue becomes empty. > >>> Queue is processed only at checkpoints. > >>> Checkpoints are met in iothread (at timers processing and so on). > >>> But iothread is waiting for finishing the drain. > >> > >> What checkpoint can hang the drain during a save? > > > > No one. There are no checkpoins during vmsave and during drain. > > Therefore the queue will never become empty. > > Understood. And what checkpoint will you be waiting for during drain, > causing a deadlock?
Every checkpoint processes the queue, but none of them are invoked, because iothread (which invokes all the checkpoints) is waiting for the end of the drain. And we cannot add a checkpoint into the drain, because then vmstop will affect the behavior of the guest. Pavel Dovgalyuk
