Re: [Qemu-devel] [PATCH v2 2/3] hw/sd: model a power-up delay, as a workaround for an EDK2 bug

[Peter Maydell <peter.maydell@linaro.org>]

On 23 December 2015 at 19:37, Andrew Baumann
<Andrew.Baumann@microsoft.com> wrote:
>> From: Peter Maydell [mailto:peter.maydell@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