On Thu, 22 Apr 2021 at 16:41, Philippe Mathieu-Daudé <f4...@amsat.org> wrote:
> IOW new targets should use type 1.
>
>
> Looking at type 2:
>
> a) targets added 'recently' with the incorrect type 2:
>
> target/avr/cpu.c:216: cc->vmsd = &vms_avr_cpu;
> target/riscv/cpu.c:627: cc->vmsd = &vmstate_riscv_cpu;
>
> b) targets where migration isn't really an issue:
>
> target/lm32/cpu.c:244: cc->vmsd = &vmstate_lm32_cpu;
> target/moxie/cpu.c:125: cc->vmsd = &vmstate_moxie_cpu;
>
> c) targets where migration could be broken:
>
> target/mips/cpu.c:723: cc->vmsd = &vmstate_mips_cpu;
> target/sparc/cpu.c:892: cc->vmsd = &vmstate_sparc_cpu;
>
> d) KVM targets ("security boundary" or Tier-1) are left:
>
> target/arm/cpu.c:1985: cc->vmsd = &vmstate_arm_cpu;
> target/i386/cpu.c:7434: cc->vmsd = &vmstate_x86_cpu;
> target/ppc/translate_init.c.inc:10923: cc->vmsd = &vmstate_ppc_cpu;
> target/s390x/cpu.c:520: cc->vmsd = &vmstate_s390_cpu;
>
>
> Isn't "machine type" what allows us to change migration stream?
> All targets in d) do support that.
Versioned machine types allow us to change the migration stream
if we do it in a forwards-compatible way (and if we're feeling
kind to RH as a downstream perhaps even backwards-compatible);
but new QEMU still has to be able to read the migration stream
produced by old QEMU for the "virt-5.2" board, or whatever.
In some cases I think we also like to maintain migration
compat on a "best-effort" basis; I think Mark likes to handle
the SPARC guests that way.
thanks
-- PMM
