From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52341) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WxDdm-0004Td-BD for qemu-devel@nongnu.org; Wed, 18 Jun 2014 07:02:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WxDde-0000k8-Gb for qemu-devel@nongnu.org; Wed, 18 Jun 2014 07:02:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:61707) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WxDde-0000k4-86 for qemu-devel@nongnu.org; Wed, 18 Jun 2014 07:02:46 -0400 Date: Wed, 18 Jun 2014 16:32:40 +0530 From: Amit Shah Message-ID: <20140618110240.GM29732@grmbl.mre> References: <87ha3iijbi.fsf@troll.troll> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <87ha3iijbi.fsf@troll.troll> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v4 00/18] migration: add static analysis tool to check vmstate compat List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juan Quintela Cc: qemu list , Markus Armbruster , Alexander Graf , "Dr. David Alan Gilbert" , Paolo Bonzini , Andreas =?iso-8859-1?Q?F=E4rber?= On (Wed) 18 Jun 2014 [12:49:21], Juan Quintela wrote: > Amit Shah 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=E4rber. > > > > 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. >=20 > This usage should go at the beggining of the script or somewhere at Doc= umantion/ 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. >=20 > Can we add this as: >=20 > 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 w= e > 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