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

[Paolo Bonzini <pbonzini@redhat.com>]

> 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