From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38357) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNkLm-0004th-6v for qemu-devel@nongnu.org; Thu, 14 Jul 2016 13:23:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bNkLk-0006iD-3M for qemu-devel@nongnu.org; Thu, 14 Jul 2016 13:23:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40561) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNkLj-0006i5-Oc for qemu-devel@nongnu.org; Thu, 14 Jul 2016 13:23:00 -0400 From: "Dr. David Alan Gilbert (git)" Date: Thu, 14 Jul 2016 18:22:42 +0100 Message-Id: <1468516976-20140-1-git-send-email-dgilbert@redhat.com> Subject: [Qemu-devel] [PATCH v3 00/14] virtio migration: Flip outer layer to vmstate List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org, mst@redhat.com, amit.shah@redhat.com, quintela@redhat.com Cc: cornelia.huck@de.ibm.com, kraxel@redhat.com From: "Dr. David Alan Gilbert" Hi, This series converts the outer most layer of virtio to use VMState macros; this is the easy bit, but I'm hoping that having done that, the next trick is to nibble away at the virtio_save/load functions and all of the zillions of device/bus helpers. I think the first two patches are the most controversial; they remove migration support for old version of virtio-net and virtio-serial; (for virtio-net versions prior to 0.11 and for virtio-serial prior to 0.13). I'm working on the basis that migration has bit rotted enough so that the streams aren't migration compatible for that long back on upstream - but if anyone knows otherwise please shout. The reason for doing those is that the virtio structure makes it a bit tricky to pass the outer device version number down through VMState to the device specific code (I can do it as a hack if necessary using a dummy is_needed function); and with -net and -serial compatibility sorted I think every other device just supports a single version. My main reason for doing this is to get rid of the calls to register_savevm ('going to disappear as soon..' since 2010) It's lightly tested using the magic line: ./x86_64-softmmu/qemu-system-x86_64 -nographic -machine pc-i440fx-2.6,accel=kvm -cpu qemu64 -m 2048M -drive file=/home/vmimages/f20.img,if=none,id=drivea -device virtio-scsi,id=scsi -device scsi-hd,drive=drivea -device virtio-rng -device virtio-serial -chardev file,id=test,path=/tmp/testfile -device virtconsole,chardev=test,name=foo -virtfs local,path=/home,security_model=passthrough,mount_tag=host_share -device virtio-gpu -drive file=/home/vmimages/jeos-19-64.qcow2,id=jeos,if=none -device virtio-blk,drive=jeos -device virtio-balloon Thoughts? Dave v3 Change virtio-gpu to use migrate_add_blocker instead of dummy vmstate, avoiding the problem of ending up with two vmstates for the one device. Dr. David Alan Gilbert (14): virtio-net: Remove old migration version support virtio-serial: Remove old migration version support virtio: Migration helper function and macro virtio-scsi: Wrap in vmstate virtio-blk: Wrap in vmstate virtio-rng: Wrap in vmstate virtio-balloon: Wrap in vmstate virtio-net: Wrap in vmstate virtio-serial: Wrap in vmstate 9pfs: Wrap in vmstate virtio-input: Wrap in vmstate virtio-gpu: Use migrate_add_blocker for virgl migration blocking virtio-gpu: Wrap in vmstate virtio: Update migration docs docs/virtio-migration.txt | 6 ++- hw/9pfs/virtio-9p-device.c | 14 ++---- hw/block/virtio-blk.c | 16 +++---- hw/char/virtio-serial-bus.c | 62 ++++++++----------------- hw/display/virtio-gpu.c | 36 ++++++++------- hw/input/virtio-input.c | 26 +++-------- hw/net/virtio-net.c | 102 ++++++++++++++++------------------------- hw/scsi/virtio-scsi.c | 21 +++------ hw/virtio/virtio-balloon.c | 19 ++------ hw/virtio/virtio-rng.c | 20 ++------ hw/virtio/virtio.c | 6 +++ include/hw/virtio/virtio-gpu.h | 2 + include/hw/virtio/virtio.h | 20 ++++++++ 13 files changed, 145 insertions(+), 205 deletions(-) -- 2.7.4