spapr: don't migrate "spapr_option_vector_ov5_cas" to pre 2.8 machines

a324d6f166 "spapr: Support ibm,dynamic-memory-v2 property" added
a new feature in the set of CAS-negotiatable options. This causes
the CAS-negotiated options subsection to be migrated, even for old
machine types that don't know about it, and breaks backward migration
to QEMU 2.7 and older versions:

qemu-system-ppc64: error while loading state for instance 0x0 of device
 'spapr'
qemu-system-ppc64: load of migration failed: No such file or directory

Since this feature only affects boot time behaviour, it should be
filtered out when we decide to migrate CAS-negotiated options, like
we already do with OV5_FORM1_AFFINITY and OV5_DRCONF_MEMORY.

Signed-off-by: Greg Kurz <groug@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This commit is contained in:
Greg Kurz 2018-05-03 23:16:48 +02:00 committed by David Gibson
parent bce009645b
commit aef19c04bf
1 changed files with 3 additions and 1 deletions

View File

@ -1849,10 +1849,12 @@ static bool spapr_ov5_cas_needed(void *opaque)
*
* Thus, for any cases where the set of available CAS-negotiatable
* options extends beyond OV5_FORM1_AFFINITY and OV5_DRCONF_MEMORY, we
* include the CAS-negotiated options in the migration stream.
* include the CAS-negotiated options in the migration stream, unless
* if they affect boot time behaviour only.
*/
spapr_ovec_set(ov5_mask, OV5_FORM1_AFFINITY);
spapr_ovec_set(ov5_mask, OV5_DRCONF_MEMORY);
spapr_ovec_set(ov5_mask, OV5_DRMEM_V2);
/* spapr_ovec_diff returns true if bits were removed. we avoid using
* the mask itself since in the future it's possible "legacy" bits may be