[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] migration: Correctly handle subsections with no

From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH] migration: Correctly handle subsections with no 'needed' function
Date: Tue, 7 Aug 2018 16:00:06 +0100

On 7 August 2018 at 15:49, Juan Quintela <address@hidden> 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)

-- PMM

reply via email to

[Prev in Thread] Current Thread [Next in Thread]