From mboxrd@z Thu Jan 1 00:00:00 1970 From: OHMURA Kei Subject: virtio_blk_load() question Date: Thu, 18 Mar 2010 13:30:02 +0900 Message-ID: <4BA1AC4A.2070402@lab.ntt.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: Avi Kivity , Anthony Liguori , Yoshiaki Tamura , ohmura.kei@lab.ntt.co.jp To: "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" Return-path: Received: from tama50.ecl.ntt.co.jp ([129.60.39.147]:45468 "EHLO tama50.ecl.ntt.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750789Ab0CREa1 (ORCPT ); Thu, 18 Mar 2010 00:30:27 -0400 Sender: kvm-owner@vger.kernel.org List-ID: Hi, I have a question regarding virtio_blk_load(). (qemu-kvm.git d1fa468c1cc03ea362d8fe3ed9269bab4d197510) VirtIOBlockReq structure is linked list of requests, but it doesn't seem to be properly linked in virtio_blk_load(). ... req->next = s->rq; s->rq = req->next; ... In this case, we're losing req, and s->rq always point to be same entry. If I'm understanding correctly, s->rq is NULL initially, and this would be kept. Although I'm not sure how these requests should be ordered, if the requests should be added to the head of list to restore the saved status by virtio_blk_save(), I think the following code is correct. However, it seems to reverse the order of the requests, and I'm wondering whether that is appropriate. Would somebody tell me how virtio_blk_load() is working? diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c index b80402d..267b16f 100644 --- a/hw/virtio-blk.c +++ b/hw/virtio-blk.c @@ -457,7 +457,7 @@ static int virtio_blk_load(QEMUFile *f, void *opaque, int version_id) VirtIOBlockReq *req = virtio_blk_alloc_request(s); qemu_get_buffer(f, (unsigned char*)&req->elem, sizeof(req->elem)); req->next = s->rq; - s->rq = req->next; + s->rq = req; } return 0; From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ns7N8-0003ry-Pb for qemu-devel@nongnu.org; Thu, 18 Mar 2010 00:30:14 -0400 Received: from [199.232.76.173] (port=53508 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ns7N7-0003rq-Dh for qemu-devel@nongnu.org; Thu, 18 Mar 2010 00:30:13 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Ns7N4-0005v1-BS for qemu-devel@nongnu.org; Thu, 18 Mar 2010 00:30:13 -0400 Received: from tama50.ecl.ntt.co.jp ([129.60.39.147]:45461) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ns7N3-0005up-NP for qemu-devel@nongnu.org; Thu, 18 Mar 2010 00:30:10 -0400 Message-ID: <4BA1AC4A.2070402@lab.ntt.co.jp> Date: Thu, 18 Mar 2010 13:30:02 +0900 From: OHMURA Kei MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] virtio_blk_load() question List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" Cc: ohmura.kei@lab.ntt.co.jp, Avi Kivity , Yoshiaki Tamura Hi, I have a question regarding virtio_blk_load(). (qemu-kvm.git d1fa468c1cc03ea362d8fe3ed9269bab4d197510) VirtIOBlockReq structure is linked list of requests, but it doesn't seem to be properly linked in virtio_blk_load(). ... req->next = s->rq; s->rq = req->next; ... In this case, we're losing req, and s->rq always point to be same entry. If I'm understanding correctly, s->rq is NULL initially, and this would be kept. Although I'm not sure how these requests should be ordered, if the requests should be added to the head of list to restore the saved status by virtio_blk_save(), I think the following code is correct. However, it seems to reverse the order of the requests, and I'm wondering whether that is appropriate. Would somebody tell me how virtio_blk_load() is working? diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c index b80402d..267b16f 100644 --- a/hw/virtio-blk.c +++ b/hw/virtio-blk.c @@ -457,7 +457,7 @@ static int virtio_blk_load(QEMUFile *f, void *opaque, int version_id) VirtIOBlockReq *req = virtio_blk_alloc_request(s); qemu_get_buffer(f, (unsigned char*)&req->elem, sizeof(req->elem)); req->next = s->rq; - s->rq = req->next; + s->rq = req; } return 0;