On (Mon) 20 Jun 2016 [16:33:26], Paolo Bonzini wrote:
> Commit 926cde5 ("scsi: esp: make cmdbuf big enough for maximum CDB size",
> 2016-06-16) changed the size of a migrated field. Split it in two
> parts, and only migrate the second part in a new vmstate version.
With this patch, the static checker fails in this way:
Section "esp", Description "esp": expected field "cmdlen", got "cmdbuf";
skipping rest
Section "dc390", Description "esp": expected field "cmdlen", got "cmdbuf";
skipping rest
Section "am53c974", Description "esp": expected field "cmdlen", got "cmdbuf";
skipping rest
Note it doesn't complain about the version numbers. That's because:
> const VMStateDescription vmstate_esp = {
> .name ="esp",
> - .version_id = 3,
> + .version_id = 4,
> .minimum_version_id = 3,
this suggests older versions can still be accepted for incoming
migration, which isn't true. So we'll have to bump this field up too.
I tried that, and this is how the checker fails with
minimum_version_id bumped:
Section "esp" Description "esp": minimum version error: 3 < 4
Section "esp", Description "esp": expected field "cmdlen", got "cmdbuf";
skipping rest
Section "dc390" Description "esp": minimum version error: 3 < 4
Section "dc390", Description "esp": expected field "cmdlen", got "cmdbuf";
skipping rest
Section "am53c974" Description "esp": minimum version error: 3 < 4
Section "am53c974", Description "esp": expected field "cmdlen", got "cmdbuf";
skipping rest
We're at a point where we can't accept an older migration stream for
this device, right? At least that's what the version bump indicates.
One workaround would be to mark the current cmdbuf as unused, and push
the new one into a subsection. That way we can keep incoming
migrations working, but given esp migrations never worked with the
partial state earlier, we'd not be any worse-off.
Amit
