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? Paolo
