On 4/22/21 12:28 PM, Peter Maydell wrote: > On Thu, 22 Apr 2021 at 10:55, Philippe Mathieu-Daudé <f4...@amsat.org> wrote: >> My guess is CPUState is the only device used in user emulation, >> so it would be a way to restrict the vmstate_dummy to CPU and >> not to any DeviceState? >> >> But looking at the introductory commit: >> >> commit b170fce3dd06372f7bfec9a780ebcb1fce6d57e4 >> Author: Andreas Färber <afaer...@suse.de> >> Date: Sun Jan 20 20:23:22 2013 +0100 >> >> cpu: Register VMStateDescription through CPUState >> >> In comparison to DeviceClass::vmsd, CPU VMState is split in two, >> "cpu_common" and "cpu", and uses cpu_index as instance_id instead of -1. >> Therefore add a CPU-specific CPUClass::vmsd field. >> >> Unlike the legacy CPUArchState registration, rather register CPUState. >> >> Juan, do you remember? > > Oh yes, I remember this. There are two ways to handle migration for > a CPU object: > > (1) like any other device, so it has a dc->vmsd that covers > migration for the whole object. As usual for objects that are a > subclass of a parent that has state, the first entry in the > VMStateDescription field list is VMSTATE_CPU(), which migrates > the cpu_common fields, followed by whatever the CPU's own migration > fields are. > (2) a backwards-compatible mechanism for CPUs that were > originally migrated using manual "write fields to the migration > stream structures". The on-the-wire migration format > for those is based on the 'env' pointer (which isn't a QOM object), > and the cpu_common part of the migration data is elsewhere. > > cpu_exec_realizefn() handles both possibilities: > * for type 1, dc->vmsd is set and cc->vmsd is not, > so cpu_exec_realizefn() does nothing, and the standard > "register dc->vmsd for a device" code does everything needed > * for type 2, dc->vmsd is NULL and so we register the vmstate_cpu_common > directly to handle the cpu-common fields, and the cc->vmsd to handle > the per-CPU stuff > > You can't change a CPU from one type to the other without breaking > migration compatibility, which is why some guest architectures > are stuck on the cc->vmsd form. New targets should use dc->vmsd.
Doh I just post v5. I guess I'll have to revisit patch #7, because I likely blew type 2 migration: https://patchew.org/QEMU/20210422104705.2454166-1-f4...@amsat.org/20210422104705.2454166-8-f4...@amsat.org/
