[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: Juan Quintela
Subject: Re: [Qemu-devel] [PATCH] migration: Correctly handle subsections with no 'needed' function
Date: Tue, 07 Aug 2018 17:05:41 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Peter Maydell <address@hidden> wrote:
> 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)

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.

reply via email to

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