qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: marcandre.lureau@redhat.com
Cc: qemu-devel@nongnu.org,
	Samuel Thibault <samuel.thibault@ens-lyon.org>,
	qemu-block@nongnu.org, Jason Wang <jasowang@redhat.com>,
	Juan Quintela <quintela@redhat.com>,
	Leonardo Bras <leobras@redhat.com>, Kevin Wolf <kwolf@redhat.com>,
	John Snow <jsnow@redhat.com>, Hanna Reitz <hreitz@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [PATCH 4/5] RFC: migration: check required subsections are loaded, once
Date: Wed, 4 Oct 2023 12:16:21 -0400	[thread overview]
Message-ID: <ZR2P1RbxCfBdYBaQ@x1n> (raw)
In-Reply-To: <20230926155925.1396309-5-marcandre.lureau@redhat.com>

On Tue, Sep 26, 2023 at 07:59:24PM +0400, marcandre.lureau@redhat.com wrote:
> @@ -484,6 +513,13 @@ static int vmstate_subsection_load(QEMUFile *f, const VMStateDescription *vmsd,
>          }
>      }
>  
> +    for (i = 0; i < n; i++) {
> +        if (!visited[i] && vmstate_save_needed(vmsd->subsections[i], opaque)) {
> +            trace_vmstate_subsection_load_bad(vmsd->name, vmsd->subsections[i]->name, "(not visited)");
> +            return -ENOENT;
> +        }
> +    }

One thing that might be tricky to call needed() on loading side is, IMHO
the needed() hooks normally was designed to be only called on a complete VM
state. IOW, I think it can reference any machine/device state, or whatever
variable assuming all of them contain valid data.

But the load side may not yet contain everything..  we can guarantee here
we loaded the full device state of this one as subsections should be the
last to come, and all we've loaded so far.  But what if it references
something else outside what we've loaded?  It looks possible in some
special .needed() hook we can return something unexpected.

I assume most needed() hooks are fine (and it does look like we can find
bugs with this, which means this might be proved useful already at least in
some form or another). I just worry on something start to break after we
become strict on this.

Maybe.. make the check only throw warnings, but not yet fail the migration?

> +
>      trace_vmstate_subsection_load_good(vmsd->name);
>      return 0;
>  }
> -- 
> 2.41.0
> 

-- 
Peter Xu



  reply	other threads:[~2023-10-04 16:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-26 15:59 [PATCH 0/5] RFC: migration: check required entries and sections are loaded marcandre.lureau
2023-09-26 15:59 ` [PATCH 1/5] block/fdc: 'phase' is not needed on load marcandre.lureau
2023-09-26 15:59 ` [PATCH 2/5] virtio: make endian_needed() work during loading marcandre.lureau
2023-09-26 15:59 ` [PATCH 3/5] net/slirp: use different IDs for each instance marcandre.lureau
2023-09-26 15:59 ` [PATCH 4/5] RFC: migration: check required subsections are loaded, once marcandre.lureau
2023-10-04 16:16   ` Peter Xu [this message]
2023-09-26 15:59 ` [PATCH 5/5] RFC: migration: check required entries " marcandre.lureau
2023-10-04 16:26 ` [PATCH 0/5] RFC: migration: check required entries and sections are loaded Peter Xu

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=ZR2P1RbxCfBdYBaQ@x1n \
    --to=peterx@redhat.com \
    --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=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --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).