All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	qemu-devel@nongnu.org, minyard@acm.org,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>
Subject: Re: [PATCH v7 2/5] softmmu/vl: Let -fw_cfg option take a 'gen_id' argument
Date: Mon, 15 Jun 2020 16:45:27 +0200	[thread overview]
Message-ID: <20200615144527.w2637fq5jzpk7jtt@sirius.home.kraxel.org> (raw)
In-Reply-To: <6e4b9540-7d5b-0951-2870-bada03e29d83@redhat.com>

  Hi,

> > I can explain the rationale for that change, but I'm not sure of the
> > answer to your question.  That changes makes sure that the fw_cfg data
> > remains exactly the same even on newer versions of qemu if the machine
> > is set the same.  This way you can do migrations to newer qemu versions
> > and anything using fw_cfg won't get confused because the data changes.
> > 
> > The reason that change was so complex was preserving the order for
> > migrating from older versions.
> > 
> > This is only about migration.  I'm not sure what gen_id is, but if it's
> > migrated, it better be future proof.
> 
> Whenever introducing a new fw_cfg file (*any* new named file), how do we
> decide whether we need fw_cfg_set_order_override()?

The whole point of the sorting is to make sure the fw_cfg directory
listing entry (FW_CFG_FILE_DIR) is stable and doesn't change underneath
the guest when it gets live-migrated.

That sorting was added in qemu 2.6, to make sure things don't chance by
accident in case the initialization order changes.  Now you've got a
problem when you migrate from qemu 2.5 (+older) to qemu 2.6 (+newer),
because 2.5 has the entries in initialization order and 2.6 has the
entries in alphabetical order.  To deal with that machine types for 2.5
& older keep the old sort order.  This is the reason why
legacy_fw_cfg_order exists.

For new features and files you can completely ignore the whole legacy
sorting mess.  cross-version live migration works only for features
supported by both qemu versions, therefore the legacy sorting is only
relevant for features & files already supported by qemu 2.5.

HTH,
  Gerd



  parent reply	other threads:[~2020-06-15 14:46 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-28 17:31 [PATCH v7 0/5] fw_cfg: Add FW_CFG_DATA_GENERATOR; crypto: Add tls-cipher-suites Philippe Mathieu-Daudé
2020-05-28 17:31 ` [PATCH v7 1/5] hw/nvram/fw_cfg: Add the FW_CFG_DATA_GENERATOR interface Philippe Mathieu-Daudé
2020-05-29  9:09   ` Laszlo Ersek
2020-05-29  9:21     ` Philippe Mathieu-Daudé
2020-05-28 17:31 ` [PATCH v7 2/5] softmmu/vl: Let -fw_cfg option take a 'gen_id' argument Philippe Mathieu-Daudé
2020-05-29  9:50   ` Laszlo Ersek
2020-06-09 14:12     ` Philippe Mathieu-Daudé
2020-06-09 15:50     ` Corey Minyard
2020-06-11 11:31       ` Laszlo Ersek
2020-06-11 11:49         ` Philippe Mathieu-Daudé
2020-06-11 17:54           ` Corey Minyard
2020-06-15 14:45         ` Gerd Hoffmann [this message]
2020-06-15 15:02           ` Philippe Mathieu-Daudé
2020-06-16 15:23             ` Laszlo Ersek
2020-05-28 17:31 ` [RFC PATCH v7 3/5] softmmu/vl: Allow -fw_cfg 'gen_id' option to use the 'etc/' namespace Philippe Mathieu-Daudé
2020-05-29 10:10   ` Laszlo Ersek
2020-05-28 17:31 ` [PATCH v7 4/5] crypto: Add tls-cipher-suites object Philippe Mathieu-Daudé
2020-05-29 11:09   ` Laszlo Ersek
2020-05-29 11:17     ` Laszlo Ersek
2020-05-29 11:18     ` Daniel P. Berrangé
2020-05-29 12:08       ` Laszlo Ersek
2020-05-28 17:31 ` [PATCH v7 5/5] crypto/tls-cipher-suites: Produce fw_cfg consumable blob Philippe Mathieu-Daudé

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=20200615144527.w2637fq5jzpk7jtt@sirius.home.kraxel.org \
    --to=kraxel@redhat.com \
    --cc=berrange@redhat.com \
    --cc=lersek@redhat.com \
    --cc=minyard@acm.org \
    --cc=pbonzini@redhat.com \
    --cc=philmd@redhat.com \
    --cc=qemu-devel@nongnu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.