From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MlOEj-0002Ui-Jd for qemu-devel@nongnu.org; Wed, 09 Sep 2009 10:33:29 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MlOEd-0002PX-RF for qemu-devel@nongnu.org; Wed, 09 Sep 2009 10:33:27 -0400 Received: from [199.232.76.173] (port=51112 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MlOEd-0002Ow-Hh for qemu-devel@nongnu.org; Wed, 09 Sep 2009 10:33:23 -0400 Received: from mx1.redhat.com ([209.132.183.28]:1026) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MlOEc-0001h3-T5 for qemu-devel@nongnu.org; Wed, 09 Sep 2009 10:33:23 -0400 Received: from int-mx03.intmail.prod.int.phx2.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n89EXKcH011753 for ; Wed, 9 Sep 2009 10:33:21 -0400 Received: from zweiblum.home.kraxel.org (vpn2-9-67.ams2.redhat.com [10.36.9.67]) by int-mx03.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id n89EXIIr013743 for ; Wed, 9 Sep 2009 10:33:19 -0400 Message-ID: <4AA7BCAD.5070107@redhat.com> Date: Wed, 09 Sep 2009 16:33:17 +0200 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] The State of the SaveVM format References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On 09/09/09 10:47, Juan Quintela wrote: > We are here at how we want to develop the format. People that has > expressed opinions so far are: > - Gerd: You do a very simple format, and if the old state can't be > expressed in simple VMState, you just use the old load > function. This maintains VMState clean, and you can load > everything that was done before. Eventually, we remove the > old load state functions when we don't support so old format. I still think we should try to keep it as simple as possible. > - Anthony: If we leave the old load state functions, they will be > around forever. He wants to complicate^Wimprove VMState > to be able to express everything that was done in plain C. > Reason: It is better to only have _one_ set of functions. I think we can drop the load functions some day. We'll need a release (say 0.13) which is completely converted to vmstate but still can read old state via old functions. Then zap them and document that you can't go from 0.10 to 0.15 directly, but have to use 0.13 inbetween to port the saved vmstate over to the new format. > How do we deal with optional features? > - We add feature bits (something like PCI does with optional features, > the exact implementation is not important). When we add an optional > feature to a driver, we just implement the save function as: > - if we are using the feature, we add the feature bit indicating that > we are using the feature, and we save the state for that feature. > - at load time: If we find a feature that we don't understand, we > just abort the load. > - at load time: if you miss a feature that you need -> you also abort > This has a nice advantage, if you load the state from old qemu, you > don't use the new feature, and you save the state -> you can still > load the state in old qemu (this is a nice theory, we don't know how > it would work on practice). Another advantage is that you can code > and test each option separately. Michael S. Tsirkin likes this mode. Hmm. We could make the format much more verbose. Instead of storing just the values and a section version we store for each field: (1) the name (2) the type (3) for arrays the length (4) maybe field flags (5) the actual value It loadvm then will read the field name, looks it up in vmstate, checks the type, if ok load the values to the specified state struct offset. We probably want to add a default value for all fields to vmstate then. Advantages: * We don't need section versions any more (except for the jump from the old to the vmstate based section format), adding fields just works. Fields not present in the snapshot are filled with the default. * We maybe can use the vmstate default values to implement a generic device-reset function. * Dumping the snapshot in human-readable form works without access to all the vmstate structs describing the section layout. Not sure how to handle stuff like msix. I'd tend to save all state unconditionally. We could add a is_default field flag which savevm will write to signal 'actual value == default value'. In case loadvm finds a unknown field it then can ignore it if is_default is set, otherwise complain that it can't deal with the unknown state. msix would have to make sure all state fields have the default values in case msix is not in use. cheers, Gerd