On Tue, Apr 29, 2025 at 05:21:40PM +0200, Thomas Huth wrote: > From: Thomas Huth <th...@redhat.com> > > For automatic tests, we need reference files from older QEMU versions. > QEMU 7.2 is a long term stable release, so it's a good candidate for > checking whether the migration could still work correctly. Let's add the > files from that version that have been taken with the "-dump-vmstate" > parameter of QEMU (compiled with single machines and the configure switch > "--without-default-devices" to keep the json files reasonable small). > > Some devices also have been removed manually from the json files, e.g. > the "pci-bridge" (which can be disabled in later QEMU versions via Kconfig), > and some Linux-related devices like "scsi-block" and "scsi-generic" and > KVM-related devices. Without removing them, we might get errors otherwise > if these devices have not been compiled into the destination QEMU build. > > Signed-off-by: Thomas Huth <th...@redhat.com> > --- > MAINTAINERS | 1 + > .../aarch64/virt-7.2.json | 2571 +++++++++++++ > .../vmstate-static-checker/m68k/virt-7.2.json | 2936 ++++++++++++++ > .../ppc64/pseries-7.2.json | 1068 ++++++ > .../s390x/s390-ccw-virtio-7.2.json | 475 +++ > .../x86_64/pc-q35-7.2.json | 3402 +++++++++++++++++ > 6 files changed, 10453 insertions(+) > create mode 100644 tests/data/vmstate-static-checker/aarch64/virt-7.2.json > create mode 100644 tests/data/vmstate-static-checker/m68k/virt-7.2.json > create mode 100644 tests/data/vmstate-static-checker/ppc64/pseries-7.2.json > create mode 100644 > tests/data/vmstate-static-checker/s390x/s390-ccw-virtio-7.2.json > create mode 100644 tests/data/vmstate-static-checker/x86_64/pc-q35-7.2.json
This looks like an improvement indeed, it so far only covers machine type 7.2, rather than all machine types. I used to run these by hands before each release.. and sometimes I forgot. Before me, I am aware at least Dave used to run also during softfreezes. One thing I am wondering is if we can do it the same way as the compat migration test in CI, so that we always compare with a base (which is the previous release binary), then move the base after each release. After all, due to migration-compat-common CI job, we always build the base version of QEMU already in build-previous-qemu, so we already have two binaries at hand. IIUC we only need one new job to generate the two JSON blobs, and feed them to the checker on both directions. If that is the case, it might have a benefit that we can cover all the machines as long as listed on both binaries, then check all of them? Meanwhile, if we keep the ball rolling for each release (by boosting the base QEMU binary version), IIUC it guarantees all the new binaries will make sure to provide compatible VMSDs all across since we start running the job. Would that work? -- Peter Xu
