On Thu, 18 May 2017 13:14:05 +0200 Halil Pasic <pa...@linux.vnet.ibm.com> wrote:
> Prior to the virtio-ccw-2.7 machine (and commit 2a79eb1a), our virtio > devices residing under the virtual-css bus do not have qdev_path based > migration stream identifiers (because their qdev_path is NULL). The ids > are instead generated when the device is registered as a composition of > the so called idstr, which takes the vmsd name as its value, and an > instance_id, which is which is calculated as a maximal instance_id > registered with the same idstr plus one, or zero (if none was registered > previously). > > That means, under certain circumstances, one device might try, and even > succeed, to load the state of a different device. This can lead to > trouble. > > Let us fail the migration if the above problem is detected during load. > > How to reproduce the problem: > 1) start qemu-system-s390x making sure you have the following devices > defined on your command line: > -device virtio-rng-ccw,id=rng1,devno=fe.0.0001 > -device virtio-rng-ccw,id=rng2,devno=fe.0.0002 > 2) detach the devices and reattach in reverse order using the monitor: > (qemu) device_del rng1 > (qemu) device_del rng2 > (qemu) device_add virtio-rng-ccw,id=rng2,devno=fe.0.0002 > (qemu) device_add virtio-rng-ccw,id=rng1,devno=fe.0.0001 > 3) save the state of the vm into a temporary file and quit QEMU: > (qemu) migrate "exec:gzip -c > /tmp/tmp_vmstate.gz" > (qemu) q > 4) use your command line from step 1 with > -incoming "exec:gzip -c -d /tmp/tmp_vmstate.gz" > appended to reproduce the problem (while trying to to load the saved vm) > > CC: qemu-sta...@nongnu.org > Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> > Reviewed-by: Dong Jia Shi <bjsdj...@linux.vnet.ibm.com> Hum, missed that one for my pull request, sorry. Reviewed-by: Cornelia Huck <cornelia.h...@de.ibm.com> Christian, can you please pick for the next set of s390x patches?
