Peter Maydell <peter.mayd...@linaro.org> wrote: > On 7 August 2018 at 15:49, Juan Quintela <quint...@redhat.com> wrote: >> But what I wonder is _why_ we want subsections that are always there. >> We have: >> >> - normal sections >> int32_t foo >> int64_t bad; >> >> - subsections (always optional) >> if needed(whatever) >> int16_t foo2 >> int32_t bar2 >> >> So needed_always means that it is never optional, it is always sent. >> Here we have two cases: >> >> - migration from old qemu (subsction don't exist) to new qemu works >> then the subsection clearly is mandatory >> >> - migration from old qemu to new qemu don't work, because there are >> missing bits: >> then there is not problem adding the fields to the toplevel section >> and increasing the version number, because we can't migrate from >> older versions. >> >> I can't see how to can make both claims true at the same time. > > The usual situation is: > * we write a device, but it's missing some bit of functionality > and so is missing some internal state > * later, we add that functionality, and the internal state, and > now we want to add that state to the migration struct > * we would like to not break migration from the old QEMU to > the new one in the (fairly common) case where actually the > guest wasn't using that bit of the device and doesn't care > about its state > > We could do that by putting the fields into the existing > vmstate struct, and marking them as only being present in > newer versions. But using migration version numbers is > brittle, especially if sometimes a feature might be backported > to an earlier version, or if downstreams make changes. > So it's better to use a needed-always subsection, which will give > the desired behaviour: > * new QEMU -> new QEMU: state is always migrated > * old QEMU -> new QEMU: migration doesn't fail, and guest > will work assuming it didn't care about this corner of the > device's functionality (the device will end up with state > as it was at reset, or possibly special-cased via > pre_load/post_load hooks for the "section not present" case)
we break by definiton new QEMU -M <old machine type> into old QEMU. That is the whole point why I don't like that. But I understand your point. We have to decide if we care about making: QEMU-x.y -M board-x.y QEMU-z.y -M board-x.y working more or less. Later, Juan.
