From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57146) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ydezo-00064p-5h for qemu-devel@nongnu.org; Thu, 02 Apr 2015 09:17:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ydezk-00047V-LH for qemu-devel@nongnu.org; Thu, 02 Apr 2015 09:17:20 -0400 Received: from mail-wi0-x22f.google.com ([2a00:1450:400c:c05::22f]:37109) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ydezk-00047O-9R for qemu-devel@nongnu.org; Thu, 02 Apr 2015 09:17:16 -0400 Received: by wiaa2 with SMTP id a2so104922931wia.0 for ; Thu, 02 Apr 2015 06:17:15 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <551D4157.4070108@redhat.com> Date: Thu, 02 Apr 2015 15:17:11 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <55128084.2040304@huawei.com> <87a8z12yot.fsf@neno.neno> <5513793B.6020909@cn.fujitsu.com> <874mp8xd9k.fsf@neno.neno> <551D0888.3000705@cn.fujitsu.com> In-Reply-To: <551D0888.3000705@cn.fujitsu.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [Migration Bug? ] Occasionally, the content of VM's memory is inconsistent between Source and Destination of migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wen Congyang , quintela@redhat.com, Kevin Wolf , Stefan Hajnoczi , Michael Tsirkin Cc: hangaohuai@huawei.com, zhanghailiang , Li Zhijian , qemu-devel@nongnu.org, "Dr. David Alan Gilbert (git)" , "Gonglei (Arei)" , Amit Shah , peter.huangpeng@huawei.com, david@gibson.dropbear.id.au On 02/04/2015 11:14, Wen Congyang wrote: > From ebc024702dd3147e0cbdfd173c599103dc87796c Mon Sep 17 00:00:00 2001 > From: Wen Congyang > Date: Thu, 2 Apr 2015 16:28:17 +0800 > Subject: [PATCH] fix qiov size > > Signed-off-by: Wen Congyang > --- > hw/block/virtio-blk.c | 15 +++++++++++++++ > include/hw/virtio/virtio-blk.h | 1 + > 2 files changed, 16 insertions(+) > > diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c > index 000c38d..13967bc 100644 > --- a/hw/block/virtio-blk.c > +++ b/hw/block/virtio-blk.c > @@ -33,6 +33,7 @@ VirtIOBlockReq *virtio_blk_alloc_request(VirtIOBlock *s) > VirtIOBlockReq *req = g_slice_new(VirtIOBlockReq); > req->dev = s; > req->qiov.size = 0; > + req->size = 0; > req->next = NULL; > req->mr_next = NULL; > return req; > @@ -97,12 +98,20 @@ static void virtio_blk_rw_complete(void *opaque, int ret) > * external iovec. It was allocated in submit_merged_requests > * to be able to merge requests. */ > qemu_iovec_destroy(&req->qiov); > + > + /* Restore qiov->size here */ > + req->qiov.size = req->size; At this point the iovec has been destroyed. It's clearer, I think, to just use req->size in virtio_blk_complete_request (as you suggest in the comment below!). For dataplane you'll need to do the same in complete_request_vring. I'll send a patch to the mailing list, please test it---and then the block device people can merge it. Paolo > } > > if (ret) { > int p = virtio_ldl_p(VIRTIO_DEVICE(req->dev), &req->out.type); > bool is_read = !(p & VIRTIO_BLK_T_OUT); > if (virtio_blk_handle_rw_error(req, -ret, is_read)) { > + /* > + * FIXME: > + * The memory may be dirtied on read failure, it will > + * break live migration. > + */ > continue; > } > } > @@ -323,6 +332,12 @@ static inline void submit_requests(BlockBackend *blk, MultiReqBuffer *mrb, > struct iovec *tmp_iov = qiov->iov; > int tmp_niov = qiov->niov; > > + /* > + * Save old qiov->size, which will used in > + * virtio_blk_complete_request() > + */ > + mrb->reqs[start]->size = qiov->size; > + > /* mrb->reqs[start]->qiov was initialized from external so we can't > * modifiy it here. We need to initialize it locally and then add the > * external iovecs. */ > diff --git a/include/hw/virtio/virtio-blk.h b/include/hw/virtio/virtio-blk.h > index b3ffcd9..7d47310 100644 > --- a/include/hw/virtio/virtio-blk.h > +++ b/include/hw/virtio/virtio-blk.h > @@ -67,6 +67,7 @@ typedef struct VirtIOBlockReq { > struct virtio_blk_inhdr *in; > struct virtio_blk_outhdr out; > QEMUIOVector qiov; > + size_t size; > struct VirtIOBlockReq *next; > struct VirtIOBlockReq *mr_next; > BlockAcctCookie acct; > -- 2.1.0 PS: I don't check if virtio-scsi, virtio-net... has the similar > problem. If vhost=on, we can also reproduce this problem.