From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NCIxf-00074R-IS for qemu-devel@nongnu.org; Sun, 22 Nov 2009 15:23:07 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NCIxa-00071R-Vs for qemu-devel@nongnu.org; Sun, 22 Nov 2009 15:23:07 -0500 Received: from [199.232.76.173] (port=34124 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCIxa-00071O-Qj for qemu-devel@nongnu.org; Sun, 22 Nov 2009 15:23:02 -0500 Received: from lo.gmane.org ([80.91.229.12]:47617) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NCIxa-0008EY-8N for qemu-devel@nongnu.org; Sun, 22 Nov 2009 15:23:02 -0500 Received: from list by lo.gmane.org with local (Exim 4.50) id 1NCIxX-0001US-4h for qemu-devel@nongnu.org; Sun, 22 Nov 2009 21:22:59 +0100 Received: from 85.93.118.17 ([85.93.118.17]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 22 Nov 2009 21:22:59 +0100 Received: from pbonzini by 85.93.118.17 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 22 Nov 2009 21:22:59 +0100 From: Paolo Bonzini Date: Sun, 22 Nov 2009 21:22:27 +0100 Message-ID: References: <4B0952C9.9010803@redhat.com> <4B095D86.700@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In-Reply-To: <4B095D86.700@codemonkey.ws> Sender: news Subject: [Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org > 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