Re: [Qemu-devel] [PATCH v4 00/18] migration: add static analysis tool to check vmstate compat

[Amit Shah <amit.shah@redhat.com>]

On (Wed) 18 Jun 2014 [12:49:21], Juan Quintela wrote:
> Amit Shah <amit.shah@redhat.com> wrote:
> > Hello,
> >
> > v4:
> >  - Return value capped to 255 to prevent wrap-around (Eric Blake)
> >
> > v3:
> >  - Python script returns an error code: 0 if no errors, positive for
> >    the number of errors identified.
> >
> > v2:
> >  - Tabs->spaces (Dave Gilbert)
> >  - Several changes to the python script to make it more python-like
> >    (Vitaly Kuznetsov)
> >  - Don't store the empty fields created by VMSTATE_VALIDATE in the
> >    json output
> >
> > This series adds a static vmstate checker to check for breakage of
> > live migration by analyzing the vmstate information between different
> > QEMU versions.
> >
> > In patch 1, QEMU is modified to add a -dump-vmstate commandline
> > option, which takes a filename as the argument.  When invoked, QEMU
> > dumps the vmstate info in JSON format for the current machine type to
> > the file.  This patch is loosely based on a version from Andreas
> > Färber.
> >
> > This JSON file is then fed into the Python script introduced in patch
> > 2.  The script takes 'src' and 'dest' arguments, indicating the
> > direction of migration.  The script then performs a series of checks
> > and spews out information on inconsistencies it finds in the data.
> >
> > Two stripped-down versions of JSON dumps are included in this
> > patchset (patch 3).
> >
> > Patches 4 - 18 contain modifications to those dumps, to show the
> > checks that are performed by the script.  The result of running the
> > script against the final version of those files is appended below.
> >
> > The checks are to be performed for a particular machine type, and
> > comparing different machine types is bound to turn up false-positives:
> > e.g.
> >
> > (in a qemu 2.0 tree):
> > ./x86_64-softmmu/qemu-system-x86_64 -dump-vmstate qemu-2.0.json
> >
> > (in a qemu 2.2 tree:)
> > ./x86_64-softmmu/qemu-system-x86_64 -dump-vmstate -M pc-i440fx-2.0 \
> >    qemu-2.2-m2.0.json
> >
> > ./scripts/vmstate-static-checker.py -s qemu-2.0.json -d qemu-2.2-m2.0.json
> >
> > should not show any output.
> 
> This usage should go at the beggining of the script or somewhere at Documantion/

I've mentioned it in words instead of direct example; but sure I will
add it to the commit msg.

> > The idea is to include this script in 'make check', ensuring new
> > commits don't break migration.
> 
> Can we add this as:
> 
> make check-vmstate-sections or whatever, and then we can discuss later
> if integrate it on make check or not?

Yes, makes sense.

> I would assume something like:
> - dump things on qemu-2.0 (yes, need to be done by hand applying the
>   first patch)
> - dump things on current qemu as qemu-2.1, qemu-2.0.95 or whatever
> - check what changed from 2.0 and form last saved from 2.1, so we can
>   commit the changes that we are happy with and reverse the ones that we
>   are not happy with

I'm thinking each 'git push' gets us a upstream.json file somewhere,
so a 'make check' or 'make check-vmstate-sections' as you suggest
above compares against the current upstream, so the script flags any
breakage in this patch series (assuming 'make check' is run on top of
a patch series against origin/master).

If all goes according to plan (TM), we will never have a situation
where we commit stuff and then have to revert it -- because things
will be flagged in 'make check' before any push operation.


		Amit