qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 00/13] virtio migration: Flip outer layer to vms


From: Dr. David Alan Gilbert
Subject: Re: [Qemu-devel] [PATCH 00/13] virtio migration: Flip outer layer to vmstate
Date: Wed, 22 Jun 2016 11:54:21 +0100
User-agent: Mutt/1.6.1 (2016-04-27)

* Cornelia Huck (address@hidden) wrote:
> On Tue, 21 Jun 2016 20:13:54 +0100
> "Dr. David Alan Gilbert (git)" <address@hidden> wrote:
> 
> > From: "Dr. David Alan Gilbert" <address@hidden>
> > 
> > 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).
> 
> These seem rather ancient and we would not care from a s390x
> perspective. Others may think differently, though...
> 
> > 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)
> 
> Real Soon Now :) Thank you for tackling virtio!

More tickling rather than tackling; plenty of scary bits left.

> > 
> > 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?
> 
> Do you have a git tree to test somewhere? I'll take a look at the
> patches later, but it would be good if we could give it a quick test on
> s390x as well.

I've just pushed it to:
  https://github.com/dagrh/qemu.git

  on the virtio-mig branch, tag dag-virtio-mig-20160622

Thanks.

Dave

> 
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK



reply via email to

[Prev in Thread] Current Thread [Next in Thread]