| Message ID | 20231024084043.2926316-10-marcandre.lureau@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | RFC: migration: check required entries and sections are loaded | expand |
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? Later, Juan.
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...
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.
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. If the new data is only needed in a rare case, then the subsection can be made conditional on that case and the migration will still