aboutsummaryrefslogtreecommitdiff
path: root/hw
diff options
context:
space:
mode:
authorDavid Gibson <david@gibson.dropbear.id.au>2017-06-02 12:26:11 +1000
committerDavid Gibson <david@gibson.dropbear.id.au>2017-06-30 14:03:31 +1000
commitd5fc133eed862b815a5eb421ad60cc73ed13c74c (patch)
tree685ed0f3846245e9f9e72e9add112a5ae1cad785 /hw
parent66d5c492dd3a92fbb6f01f3957fbe3fe5a18613e (diff)
ppc: Rework CPU compatibility testing across migration
Migrating between different CPU versions is a bit complicated for ppc. A long time ago, we ensured identical CPU versions at either end by checking the PVR had the same value. However, this breaks under KVM HV, because we always have to use the host's PVR - it's not virtualized. That would mean we couldn't migrate between hosts with different PVRs, even if the CPUs are close enough to compatible in practice (sometimes identical cores with different surrounding logic have different PVRs, so this happens in practice quite often). So, we removed the PVR check, but instead checked that several flags indicating supported instructions matched. This turns out to be a bad idea, because those instruction masks are not architected information, but essentially a TCG implementation detail. So changes to qemu internal CPU modelling can break migration - this happened between qemu-2.6 and qemu-2.7. That was addressed by 146c11f1 "target-ppc: Allow eventual removal of old migration mistakes". Now, verification of CPU compatibility across a migration basically doesn't happen. We simply ignore the PVR of the incoming migration, and hope the cpu on the destination is close enough to work. Now that we've cleaned up handling of processor compatibility modes for pseries machine type, we can do better. For new machine types (pseries-2.10+) We allow migration if: * The source and destination PVRs are for the same type of CPU, as determined by CPU class's pvr_match function OR * When the source was in a compatibility mode, and the destination CPU supports the same compatibility mode For older machine types we retain the existing behaviour - current CAS code will usually set a compat mode which would break backwards migration if we made them use the new behaviour. [Fixed from an earlier version by Greg Kurz]. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Tested-by: Andrea Bolognani <abologna@redhat.com>
Diffstat (limited to 'hw')
-rw-r--r--hw/ppc/spapr.c7
1 files changed, 6 insertions, 1 deletions
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 81007b9d4e..52f4e72b07 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -3362,7 +3362,12 @@ DEFINE_SPAPR_MACHINE(2_10, "2.10", true);
* pseries-2.9
*/
#define SPAPR_COMPAT_2_9 \
- HW_COMPAT_2_9
+ HW_COMPAT_2_9 \
+ { \
+ .driver = TYPE_POWERPC_CPU, \
+ .property = "pre-2.10-migration", \
+ .value = "on", \
+ }, \
static void spapr_machine_2_9_instance_options(MachineState *machine)
{