> From: Paolo Bonzini [mailto:[email protected]] > On 04/05/2017 14:10, Pavel Dovgalyuk wrote: > >> From: Paolo Bonzini [mailto:[email protected]] > >> On 04/05/2017 13:54, Pavel Dovgalyuk wrote: > >>>> From: Paolo Bonzini [mailto:[email protected]] > >>>> 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. Pavel Dovgalyuk
