On 4/22/21 5:53 PM, Peter Maydell wrote:
> 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.
What I don't understand if is there is a possibility to eventually
remove the CPUClass::vmsd (even long and painful), or if it is
directly impossible and we are doomed to keep maintaining both.
