From: "Michael S. Tsirkin" <mst@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: pbonzini@redhat.com, "Gabriel L. Somlo" <somlo@cmu.edu>,
lersek@redhat.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] fw cfg files cross-version migration races
Date: Mon, 8 Jun 2015 11:43:32 +0200 [thread overview]
Message-ID: <20150608114309-mutt-send-email-mst@redhat.com> (raw)
In-Reply-To: <1433748105.5046.6.camel@redhat.com>
On Mon, Jun 08, 2015 at 09:21:45AM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > > So, sorting entries (and the index assigned too) should fix this, right?
> > > That looks easiest to me.
> >
> > Presumably, anything happening before (and after) user-provided blobs
> > are inserted will continue happening in the same order everywhere.
>
> Which might change in the future though, in case the initialization
> order changes for some reason. It's not a problem we have at the
> moment, so this stuff isn't urgent. But we might face it in the future.
>
> > So we really only have to sort the user provided blobs, so that if
> > the same *set* is provided on both ends of the migration, things would
> > work out OK.
>
> I would simply sort everything (and do it for new machine types only,
> for backward compatibility reasons). Sorting user-provided blobs only
> adds complexity for no reason.
>
> > If a *different* set of blobs is specified on the migration origin vs.
> > the migration destination, we lose by default and worrying about it is
> > pointless -- did I get that right ?
>
> Yes. For migration to succeed you have to supply the same configuration
> on both ends. That includes user-provided fw_cfg blobs of course.
>
> cheers,
> Gerd
>
Do we want this for all machine types, or only for new ones?
--
MST
next prev parent reply other threads:[~2015-06-08 9:43 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-01 14:10 [Qemu-devel] fw cfg files cross-version migration races Michael S. Tsirkin
2015-06-01 14:13 ` Daniel P. Berrange
2015-06-01 15:32 ` Gabriel L. Somlo
2015-06-01 15:44 ` Michael S. Tsirkin
2015-06-01 18:00 ` Gabriel L. Somlo
2015-06-01 20:31 ` Gabriel L. Somlo
2015-06-02 7:04 ` Laszlo Ersek
2015-06-02 7:11 ` Gerd Hoffmann
2015-06-03 8:31 ` Paolo Bonzini
2015-06-03 16:03 ` Michael S. Tsirkin
2015-06-05 16:05 ` Gabriel L. Somlo
2015-06-08 7:21 ` Gerd Hoffmann
2015-06-08 9:43 ` Michael S. Tsirkin [this message]
2015-06-08 11:19 ` Gerd Hoffmann
2015-06-08 11:44 ` Paolo Bonzini
2015-06-08 12:23 ` Gabriel L. Somlo
2015-06-08 12:28 ` Paolo Bonzini
2015-06-08 12:33 ` Gerd Hoffmann
2015-06-08 13:32 ` Gabriel L. Somlo
2015-06-08 15:53 ` Michael S. Tsirkin
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=20150608114309-mutt-send-email-mst@redhat.com \
--to=mst@redhat.com \
--cc=kraxel@redhat.com \
--cc=lersek@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=somlo@cmu.edu \
/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).