qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Juan Quintela <quintela@redhat.com>
To: "Marc-André Lureau" <marcandre.lureau@redhat.com>
Cc: qemu-devel@nongnu.org,  Kevin Wolf <kwolf@redhat.com>,
	 "Michael S. Tsirkin" <mst@redhat.com>,
	 Fabiano Rosas <farosas@suse.de>,  John Snow <jsnow@redhat.com>,
	 Hanna Reitz <hreitz@redhat.com>,
	 Leonardo Bras <leobras@redhat.com>,
	 Samuel Thibault <samuel.thibault@ens-lyon.org>,
	qemu-block@nongnu.org,  Peter Xu <peterx@redhat.com>,
	 Jason Wang <jasowang@redhat.com>
Subject: Re: [PATCH v2 9/9] docs/migration: reflect the changes about needed subsections
Date: Tue, 24 Oct 2023 13:08:03 +0200	[thread overview]
Message-ID: <87jzrcz3ak.fsf@secure.mitica> (raw)
In-Reply-To: <CAMxuvazf9_j=oqOrpCAcmhsai3n6rWBSa_X-bZXkRVQum7BQQQ@mail.gmail.com> ("Marc-André Lureau"'s message of "Tue, 24 Oct 2023 14:58:08 +0400")

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	other threads:[~2023-10-24 11:09 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-24  8:40 [PATCH v2 0/9] RFC: migration: check required entries and sections are loaded marcandre.lureau
2023-10-24  8:40 ` [PATCH v2 1/9] block/fdc: 'phase' is not needed on load marcandre.lureau
2023-10-24  8:40 ` [PATCH v2 2/9] virtio: make endian_needed() work during loading marcandre.lureau
2023-10-24  8:40 ` [PATCH v2 3/9] net/slirp: use different IDs for each instance marcandre.lureau
2023-10-24  9:26   ` Juan Quintela
2023-10-24  8:40 ` [PATCH v2 4/9] migration: rename vmstate_save_needed->vmstate_section_needed marcandre.lureau
2023-10-24 10:35   ` Juan Quintela
2023-10-24  8:40 ` [PATCH v2 5/9] migration: check required subsections are loaded, once marcandre.lureau
2023-10-24 10:41   ` Juan Quintela
2023-10-24 20:10     ` Peter Xu
2023-10-24  8:40 ` [PATCH v2 6/9] migration: check required entries " marcandre.lureau
2023-10-24 10:44   ` Juan Quintela
2023-10-24  8:40 ` [PATCH v2 7/9] migration: set file error on subsection loading marcandre.lureau
2023-10-24  9:27   ` Juan Quintela
2023-10-24  8:40 ` [PATCH v2 8/9] test-vmstate: add some subsection tests marcandre.lureau
2023-10-24 10:45   ` Juan Quintela
2023-10-24  8:40 ` [PATCH v2 9/9] docs/migration: reflect the changes about needed subsections marcandre.lureau
2023-10-24 10:47   ` Juan Quintela
2023-10-24 10:58     ` Marc-André Lureau
2023-10-24 11:08       ` Juan Quintela [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87jzrcz3ak.fsf@secure.mitica \
    --to=quintela@redhat.com \
    --cc=farosas@suse.de \
    --cc=hreitz@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=leobras@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=mst@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=samuel.thibault@ens-lyon.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).