From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55245) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d6Fam-0002Ni-QU for qemu-devel@nongnu.org; Thu, 04 May 2017 08:10:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d6Fai-0004e7-SZ for qemu-devel@nongnu.org; Thu, 04 May 2017 08:10:44 -0400 Received: from mail.ispras.ru ([83.149.199.45]:35322) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d6Fai-0004dh-JJ for qemu-devel@nongnu.org; Thu, 04 May 2017 08:10:40 -0400 From: "Pavel Dovgalyuk" References: <20170504084135.7488.24715.stgit@PASHA-ISP> <20170504084210.7488.37561.stgit@PASHA-ISP> <000401d2c4c7$6d5b6d50$481247f0$@ru> <000801d2c4cd$3d3af720$b7b0e560$@ru> <58398574-88b5-3382-65e2-7208beccc09a@redhat.com> In-Reply-To: <58398574-88b5-3382-65e2-7208beccc09a@redhat.com> Date: Thu, 4 May 2017 15:10:43 +0300 Message-ID: <000f01d2c4cf$7479f630$5d6de290$@ru> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: ru Subject: Re: [Qemu-devel] [PATCH v9 06/10] replay: fix save/load vm for non-empty queue List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: 'Paolo Bonzini' , 'Pavel Dovgalyuk' , qemu-devel@nongnu.org Cc: kwolf@redhat.com, peter.maydell@linaro.org, mst@redhat.com, jasowang@redhat.com, quintela@redhat.com, kraxel@redhat.com > From: Paolo Bonzini [mailto:pbonzini@redhat.com] > On 04/05/2017 13:54, Pavel Dovgalyuk wrote: > >> From: Paolo Bonzini [mailto:pbonzini@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. Pavel Dovgalyuk