Re: [Qemu-devel] The State of the SaveVM format

[Gerd Hoffmann]

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