From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36765) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ydgw0-0002Ff-1q for qemu-devel@nongnu.org; Thu, 02 Apr 2015 11:21:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ydgvu-0007NN-R2 for qemu-devel@nongnu.org; Thu, 02 Apr 2015 11:21:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48548) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ydgvu-0007NC-Jr for qemu-devel@nongnu.org; Thu, 02 Apr 2015 11:21:26 -0400 Message-ID: <551D5E61.7090305@redhat.com> Date: Thu, 02 Apr 2015 17:21:05 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1427981862-19783-1-git-send-email-pbonzini@redhat.com> <20150402143952.GJ15412@fam-t430.nay.redhat.com> <551D578B.5050102@redhat.com> <20150402151650.GK15412@fam-t430.nay.redhat.com> In-Reply-To: <20150402151650.GK15412@fam-t430.nay.redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] virtio-blk: correctly dirty guest memory List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng Cc: kwolf@redhat.com, hangaohuai@huawei.com, zhang.zhanghailiang@huawei.com, lizhijian@cn.fujitsu.com, mst@redhat.com, qemu-devel@nongnu.org, dgilbert@redhat.com, arei.gonglei@huawei.com, stefanha@redhat.com, amit.shah@redhat.com, dgibson@redhat.com, peter.huangpeng@huawei.com On 02/04/2015 17:16, Fam Zheng wrote: >>>> > >> After qemu_iovec_destroy, the QEMUIOVector's size is zeroed and >>>> > >> the zero size ultimately is used to compute virtqueue_push's len >>>> > >> argument. Therefore, reads from virtio-blk devices did not >>>> > >> migrate their results correctly. (Writes were okay). >>> > > >>> > > Can't we move qemu_iovec_destroy to virtio_blk_free_request? >> > >> > You would still have to add more code to differentiate reads and >> > writes---I think. > Yeah, but the extra field will not be needed. Can you post an alternative patch? One small complication is that is_write is in mrb but not in mrb->reqs[x]. virtio_blk_rw_complete is already doing int p = virtio_ldl_p(VIRTIO_DEVICE(req->dev), &req->out.type); bool is_read = !(p & VIRTIO_BLK_T_OUT); but only in a slow path. Paolo