Re: [PATCH v3 01/27] target: Set CPUClass::vmsd instead of DeviceClass::vmsd

[Peter Maydell]

On Thu, 22 Apr 2021 at 16:41, Philippe Mathieu-Daudé <f4bug@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