From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36531) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ti49d-0002t7-5T for qemu-devel@nongnu.org; Mon, 10 Dec 2012 09:16:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ti49W-0005pc-Vt for qemu-devel@nongnu.org; Mon, 10 Dec 2012 09:16:21 -0500 Received: from mail-ia0-f179.google.com ([209.85.210.179]:35335) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ti49W-0005pV-RI for qemu-devel@nongnu.org; Mon, 10 Dec 2012 09:16:14 -0500 Received: by mail-ia0-f179.google.com with SMTP id o25so4009521iad.24 for ; Mon, 10 Dec 2012 06:16:13 -0800 (PST) From: Anthony Liguori In-Reply-To: <87hanyg37l.fsf@rustcorp.com.au> References: <87624iikcw.fsf@rustcorp.com.au> <87zk1uca8z.fsf@elfo.mitica> <87r4n5h0fx.fsf@rustcorp.com.au> <20121205110807.GA10045@redhat.com> <87obi7g1k5.fsf@rustcorp.com.au> <20121206080221.GC10837@redhat.com> <87hanyg37l.fsf@rustcorp.com.au> Date: Mon, 10 Dec 2012 08:16:11 -0600 Message-ID: <87r4myhu1g.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [PATCH] virtio: verify that all outstanding buffers are flushed (was Re: vmstate conversion for virtio?) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Rusty Russell , "Michael S. Tsirkin" Cc: David Gibson , QEMU-devel , quintela@redhat.com Rusty Russell writes: > "Michael S. Tsirkin" writes: > > No, because I don't understand it. Is it true for the case of > virtio_blk, which has outstanding requests? > >>> Currently we dump a massive structure; it's inelegant at the very >>> least. Inelegant is a kind word.. There's a couple things to consider though which is why this code hasn't changed so far. 1) We're writing native endian values to the wire. This is seriously broken. Just imagine trying to migrate from qemu-system-i386 on an big endian box to a little endian box. 2) Fixing (1) either means (a) breaking migration across the board gracefully or (b) breaking migration on [big|little] endian hosts in an extremely ungraceful way. 3) We send a ton of crap over the wire that is unnecessary, but we need to maintain it. I wrote up a patch series to try to improve the situation that I'll send out. I haven't gotten around to testing it with an older version of QEMU yet. I went for 2.b and choose to break big endian hosts. >>> >>> Cheers, >>> Rusty. >> >> Hmm not sure what you refer to. I see this per ring: >> >> qemu_put_be32(f, vdev->vq[i].vring.num); >> qemu_put_be64(f, vdev->vq[i].pa); >> qemu_put_be16s(f, &vdev->vq[i].last_avail_idx); >> >> Looks like there's no way around savng these fields. Correct. Regards, Anthony Liguori > > Not what I'm referring to. See here: > > virtio.h defines a 48k structure: > > #define VIRTQUEUE_MAX_SIZE 1024 > > typedef struct VirtQueueElement > { > unsigned int index; > unsigned int out_num; > unsigned int in_num; > hwaddr in_addr[VIRTQUEUE_MAX_SIZE]; > hwaddr out_addr[VIRTQUEUE_MAX_SIZE]; > struct iovec in_sg[VIRTQUEUE_MAX_SIZE]; > struct iovec out_sg[VIRTQUEUE_MAX_SIZE]; > } VirtQueueElement; > > virtio-blk.c uses it in its request struct: > > typedef struct VirtIOBlockReq > { > VirtIOBlock *dev; > VirtQueueElement elem; > struct virtio_blk_inhdr *in; > struct virtio_blk_outhdr *out; > struct virtio_scsi_inhdr *scsi; > QEMUIOVector qiov; > struct VirtIOBlockReq *next; > BlockAcctCookie acct; > } VirtIOBlockReq; > > ... and saves it in virtio_blk_save: > > static void virtio_blk_save(QEMUFile *f, void *opaque) > { > VirtIOBlock *s = opaque; > VirtIOBlockReq *req = s->rq; > > virtio_save(&s->vdev, f); > > while (req) { > qemu_put_sbyte(f, 1); > qemu_put_buffer(f, (unsigned char*)&req->elem, sizeof(req->elem)); > req = req->next; > } > qemu_put_sbyte(f, 0); > } > > Cheers, > Rusty.