qemu-block
[Top][All Lists]
Advanced

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

Re: [PATCH v2 9/9] docs/migration: reflect the changes about needed subs


From: Juan Quintela
Subject: Re: [PATCH v2 9/9] docs/migration: reflect the changes about needed subsections
Date: Tue, 24 Oct 2023 13:08:03 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.3 (gnu/linux)

Marc-André Lureau <marcandre.lureau@redhat.com> wrote:
> Hi
>
> On Tue, Oct 24, 2023 at 2:47 PM Juan Quintela <quintela@redhat.com> wrote:
>>
>> marcandre.lureau@redhat.com wrote:
>> > From: Marc-André Lureau <marcandre.lureau@redhat.com>
>> >
>> > Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
>> > ---
>> >  docs/devel/migration.rst | 17 ++++++++---------
>> >  1 file changed, 8 insertions(+), 9 deletions(-)
>> >
>> > diff --git a/docs/devel/migration.rst b/docs/devel/migration.rst
>> > index c3e1400c0c..50f313f178 100644
>> > --- a/docs/devel/migration.rst
>> > +++ b/docs/devel/migration.rst
>> > @@ -240,17 +240,16 @@ a newer form of device, or adding that state that 
>> > you previously
>> >  forgot to migrate.  This is best solved using a subsection.
>> >
>> >  A subsection is "like" a device vmstate, but with a particularity, it
>> > -has a Boolean function that tells if that values are needed to be sent
>> > -or not.  If this functions returns false, the subsection is not sent.
>> > -Subsections have a unique name, that is looked for on the receiving
>> > -side.
>> > +has a Boolean function that tells if that values are needed or not. If
>> > +this functions returns false, the subsection is not sent. Subsections
>> > +have a unique name, that is looked for on the receiving side.
>> >
>> >  On the receiving side, if we found a subsection for a device that we
>> > -don't understand, we just fail the migration.  If we understand all
>> > -the subsections, then we load the state with success.  There's no check
>> > -that a subsection is loaded, so a newer QEMU that knows about a subsection
>> > -can (with care) load a stream from an older QEMU that didn't send
>> > -the subsection.
>> > +don't understand, we just fail the migration. If we understand all the
>> > +subsections, then we load the state with success. There's no check
>> > +that an optional subsection is loaded, so a newer QEMU that knows
>> > +about a subsection can (with care) load a stream from an older QEMU
>> > +that didn't send the subsection.
>>
>> Reviewed-by: Juan Quintela <quintela@redhat.com>
>>
>> Just wondering.  What device propmted you to write this series?
>
> When I worked on ramfb, I did various testing with the subsection
> handling and was surprised by the default lazy behaviour. I initially
> thought it was a bug to ignore missing sections (both needed and
> not-needed), then I realize from the doc that it was partially by
> design. I thought it was clearer to make "needed' section actually
> required on load as well. I wonder though of the potential of breakage
> from old QEMU versions, how do we test cross-version migration? Do you
> think also "needed" section are actually required? Perhaps we need
> better wording and documentation instead...

This was designed for a world that no longer exists.
We used to "promise" that we will allow migration for:

$ qemu-n -M pc -> qemu-(n+1) -M pc

And pray that it worked.

We have dropped that long ago (as imposible to do/test).  And now we
only promise that:

$ qemu-n -M pc-n -> qemu-(n+1) -M pc-n

And in this case, making the needed versions required looks like a good
idea to me.

As said, waiting for others to chime in.
The changes that are independent are already on my queue.

Thanks, Juan.




reply via email to

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