On 23 December 2015 at 19:37, Andrew Baumann <andrew.baum...@microsoft.com> wrote: >> From: Peter Maydell [mailto:peter.mayd...@linaro.org] >> If we care about migration compatibility I think the recommendation > ^^^^^^^^^^ >> is to use subsections, rather than marking fields as only existing >> in particular versions. (see docs/migration.txt for a discussion >> of subsections). > > Do we care about migration compatibility for this code?
This is a good question. The answer might well be 'no', but it's pretty hard to tell because the SD card model is used by a lot of machines. (For devices that are board-specific it's much easier to say.) I think that getting migration compatibility right is probably the better approach; it's not that much harder. So we should use a subsection for the new data. There's some reasonably good documentation on how to do that in docs/migration.txt (in the 'Subsections' subsection :-)). > (As far as I can tell, this only matters for migration of SD interfaces > across qemu versions, where the previous state was saved in the window > between reset and driver initialisation.) If you just add fields, as your patch does, then you break migration completely across versions, whatever the state of the incoming device, because the size of the data incoming will be different. If you don't bump the version number in the vmstate struct then it will go wrong in a confusing way whereby the reader gets out of sync with the incoming data (probably resulting in an error when the next device along tries to slurp in its data). If you do bump the version number you at least get a comprehensible error message. (This all happens because our migration data stream is not self-describing: we rely on both ends having the same interpretation of the serialised data.) thanks -- PMM
