[Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts

[Paolo Bonzini]

> I don't see how this fixes anything. If you used feature bits, how do
> you migrate from a version that has a feature bit that an older version
> doesn't know about? Do you just ignore it?

I'd go with chunk instead of feature bits, specifying them like in the 
PNG specification:

      Each chunk consists of four parts:

      Length
         A 4-byte unsigned integer giving the number of bytes in the
         chunk's data field. The length counts only the data field, not
         itself, the chunk type code, or the CRC.  Zero is a valid
         length.  Although encoders and decoders should treat the length
         as unsigned, its value must not exceed (2^31)-1 bytes.

      Chunk Type
         A 4-byte chunk type code.  For convenience in description and
         in examining PNG files, type codes are restricted to consist of
         uppercase and lowercase ASCII letters (A-Z and a-z, or 65-90
         and 97-122 decimal).  [...]  Four bits of the type code,
         namely bit 5 (value 32) of each byte, are used to convey chunk
         properties. The property bits are an inherent part of
         the chunk name, and hence are fixed for any chunk type.

         The semantics of the property bits are:

         Ancillary bit: bit 5 of first byte
            0 (uppercase) = critical, 1 (lowercase) = ancillary.

            Chunks that are not strictly necessary in order to
            meaningfully display the contents of the file are known as
            "ancillary" chunks.  [Mandatory chunks may still be useful
            to QEMU, for example there could be a "PCI" chunk type].

         Private bit: bit 5 of second byte
            0 (uppercase) = public, 1 (lowercase) = private.

            A public chunk is one that is part of the PNG specification
            or is registered in the list of PNG special-purpose public
            chunk types.  Applications can also define private
            (unregistered) chunks for their own purposes. [This could
            mean that only savannah qemu.git can define public chunks.]

         Reserved bit: bit 5 of third byte
            Must be 0 (uppercase) in files conforming to this version of
            PNG.

            The significance of the case of the third letter of the
            chunk name is reserved for possible future expansion.

         Safe-to-copy bit: bit 5 of fourth byte
            0 (uppercase) = unsafe to copy, 1 (lowercase) = safe to
            copy.  [Would not matter for QEMU, I guess].

      Chunk Data
         The data bytes appropriate to the chunk type, if any.  This
         field can be of zero length.

      CRC
         A 4-byte CRC (Cyclic Redundancy Check) calculated on the
         preceding bytes in the chunk, including the chunk type code and
         chunk data fields, but not including the length field. The CRC
         is always present, even for chunks containing no data.

> Migration needs to be conservative. There should be only two possible
> outcomes: 1) a successful live migration or 2) graceful failure with the
> source VM still running correctly. Silently ignoring things that could
> affect the guests behavior means that it's possible that after failure,
> the guest will fail in an unexpected way.

It's up to the source to decide what information is extra.  For example, 
the state of a RNG emulation is nice-to-have, but as long as it is 
initialized from another random source on the destination you shouldn't 
care.

Paolo