Cc'ing avocado-devel for test idea. On 10/21/19 4:57 PM, Dr. David Alan Gilbert wrote: > * Philippe Mathieu-Daudé (phi...@redhat.com) wrote: >> Cc'ing Paolo/David. >> >> On 10/21/19 11:39 AM, Peter Maydell wrote: >>> On Mon, 21 Oct 2019 at 10:34, Philippe Mathieu-Daudé <phi...@redhat.com> >>> wrote: >>>> >>>> On 10/21/19 11:22 AM, Peter Maydell wrote: >>>>> On Mon, 21 Oct 2019 at 00:01, Philippe Mathieu-Daudé <phi...@redhat.com> >>>>> wrote: >>>>>> >>>>>> Signed-off-by: Philippe Mathieu-Daudé <phi...@redhat.com> >>>>>> --- >>>>> >>>>>> hw/arm/virt.c | 2 +- >>>>> >>>>> I think from a quick code scan that this is ok, but did >>>>> you test that migration compat from old to new still works? >>>>> I vaguely recall that there are some cases when adding an >>>>> owner to a memory region changes the name string used for >>>>> identifying the ramblock in migration. >>>> >>>> It seems to still works: >>>> >>>> $ make check-qtest-aarch64 V=1 >>> >>>> This test migrate the virt machine. >>>> >>>> Is this enough? >>> >>> No, you need to test migration from a QEMU binary without >>> this patchset to a QEMU binary that has it. Otherwise you're >>> only checking that the new version can migrate from itself >>> to itself. I find the easiest way to test this is just to >>> use the 'savevm' command to save a state snapshot to a >>> qcow2 disk image while running the old binary, and then run >>> 'loadvm' with the new binary and check it restored OK. >> >> I did not think if this case. >> >> I followed your blog post [*] and tested the migration works OK. >> >> Paolo, now thinking about regular testing, we should add this testing to >> patchew too. Something like: >> >> - when mainstream/master is updated, patchew build QEMU (it should be >> already mostly ccached) and generate some vm dumps with 'savevm'. >> >> - build/test the series >> >> - if series succeeded testing, run 'loadvm' tests >> >> [*] >> https://translatedcode.wordpress.com/2015/07/06/tricks-for-debugging-qemu-savevm-snapshots/ > > Avocado certainly already has an option for specifying source and > destination qemu separately; I've used that for testing > cross version in the past. > > The challenge is finding a command line/set of devices for each > architecture that's expected to be stable. > You want a command line with as big a set of devices as possible (for > coverage) yet really is tied to machine type. > > Dave > > -- > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK >