Peter Maydell <peter.mayd...@linaro.org> writes: > On Mon, 29 Jan 2024 at 13:45, Fabiano Rosas <faro...@suse.de> wrote: >> >> Peter Xu <pet...@redhat.com> writes: >> > Fundamentally, IMHO it's because QEMU as a project is used both in >> > enterprise and personal emulations. I think it might be too strict to >> > always request backward migration capability if we know some device / arch >> > is only used for personal, or educational, purposes. >> >> Do we need migration support tiers? =) > > We already have them. The tier list is:
Ah that's good. Thanks, Peter. > > * if the machine type is a versioned one, then we maintain > forwards compatibility for the versioned machine > (i.e. can migrate machine-X.Y of QEMU A.B to the > machine-X.Y of a QEMU C.D which is newer than A.B). > * if the machine type is not versioned, then we do not make > any guarantee of migration compatibility across QEMU versions. > Instead the aim is that if the user tries it it either works > or gives an error message that the migration failed > (e.g. because the version field in a VMState struct was bumped). > Migration breaks are generally called out in commit messages. > Often for machines in this tier the user is really interested > in state-save snapshots for debugging purposes, rather than > in a true cross-host-machine migration. > * some machine types do not support migration/savevm/loadvm > at all, because of devices missing VMState structs. This > is not desirable, and for new machine models we try to > ensure that they have vmstate structs as part of the minimum > quality bar, but it is true of some legacy machine types. Hm, does this mean in some cases we're requiring new models to have vmstate only to never look at them again? Or do you mean some versioned machines are currently broken? > AIUI we, in the sense of the upstream project, do not support > backwards migration compatibility (i.e. migrating a machine-X.Y > from QEMU C.D to QEMU A.B where A.B is an older version than C.D); > though some downstreams (read: RedHat) may do so. Here we still need to make a distinction between migration code and vmstate. If we simply ignore backwards migration then it might become impossible for downstreams to provide it without major modifications. But luckily this is the easy case. > > thanks > -- PMM
