@@ -48,8 +48,17 @@ This is used for RAM and block devices. It is not yet ported to vmstate.
=== What is the common infrastructure ===
-QEMU uses a QEMUFile abstraction to be able to do migration. Any type
-of migration that wants to use QEMU infrastructure has to create a
+Migration consists of a number of layers that handle different parts of the
+ QEMUFile - Buffering/reading/writing data without worrying about it's
+ contents. Versions exist for file I/O, sockets, RDMA and
+ to put data into a QEMU Block device.
+ Visitor - Visitors format data onto the QEMUFile. A binary format and
+ a BER format currently exist.
+ VMState - Represent the structure of the data for a given device with
+ support for versioning.
+Any type of migration that wants to use QEMU infrastructure has to create a
QEMUFile *qemu_fopen_ops(void *opaque,
@@ -296,3 +305,24 @@ save/send this state when we are in the middle of a pio operation
(that is what ide_drive_pio_state_needed() checks). If DRQ_STAT is
not enabled, the values on that fields are garbage and don't need to
+ASN.1/BER format migration
+In BER format migration the migration stream is described by an ASN.1 schema
+(that's defined in docs/specs/migration.schema).
+The 'asn1c' program can be used to validate a migration stream against the schema
+ - although it'll probably use a lot of memory doing it - so it's best to do it
+with a small RAM image.
+To validate an image against the schema:
+ a) Make a temporary directory and cd into it
+ b) asn1c -fcompound-names /path/to/migration.schema
+ c) make -f Makefile.am.sample CFLAGS+="-DPDU=QemuFile -DEMIT_ASN_DEBUG=1 -I."
+ d) ./progname -iber log.ber -d 2> debug > decoding
+ If it's happy the 'decoding' output should be an XML like dump of the input file;
+if it's not happy, the debug file might help you find out why (Search backwards
+from the end for the first 'Freeing' to find the point at which it detected something