From: Laszlo Ersek <lersek@redhat.com>
To: Michal Privoznik <mprivozn@redhat.com>,
Eric Blake <eblake@redhat.com>,
"Daniel P. Berrange" <berrange@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Kevin Wolf <kwolf@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
Juan Quintela <quintela@redhat.com>,
David Gilbert <dgilbert@redhat.com>,
Laszlo Ersek <lersek@redhat.com>,
qemu devel list <qemu-devel@nongnu.org>
Subject: [Qemu-devel] [PATCH 2/2] pflash_cfi01: write flash contents to bdrv on incoming migration
Date: Sat, 23 Aug 2014 12:19:07 +0200 [thread overview]
Message-ID: <1408789147-18675-3-git-send-email-lersek@redhat.com> (raw)
In-Reply-To: <1408789147-18675-1-git-send-email-lersek@redhat.com>
A drive that backs a pflash device is special:
- it is very small,
- its entire contents are kept in a RAMBlock at all times, covering the
guest-phys address range that provides the guest's view of the emulated
flash chip.
The pflash device model keeps the drive (the host-side file) and the
guest-visible flash contents in sync. When migrating the guest, the
guest-visible flash contents (the RAMBlock) is migrated by default, but on
the target host, the drive (the host-side file) remains in full sync with
the RAMBlock only if:
- the source and target hosts share the storage underlying the pflash
drive,
- or the migration requests full or incremental block migration too, which
then covers all drives.
Due to the special nature of pflash drives, the following scenario makes
sense as well:
- no full nor incremental block migration, covering all drives, alongside
the base migration (justified eg. by shared storage for "normal" (big)
drives),
- non-shared storage for pflash drives.
In this case, currently only those portions of the flash drive are updated
on the target disk that the guest reprograms while running on the target
host.
In order to restore accord, dump the entire flash contents to the bdrv in
a post_load() callback.
- The read-only check follows the other call-sites of pflash_update();
- both "pfl->ro" and pflash_update() reflect / consider the case when
"pfl->bs" is NULL;
- the total size of the flash device is calculated as in
pflash_cfi01_realize().
When using shared storage, or requesting full or incremental block
migration along with the normal migration, the patch should incur a
harmless rewrite from the target side.
It is assumed that, on the target host, RAM is loaded ahead of the call to
pflash_post_load().
Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
hw/block/pflash_cfi01.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/hw/block/pflash_cfi01.c b/hw/block/pflash_cfi01.c
index fddef39..593fbc5 100644
--- a/hw/block/pflash_cfi01.c
+++ b/hw/block/pflash_cfi01.c
@@ -94,10 +94,13 @@ struct pflash_t {
void *storage;
};
+static int pflash_post_load(void *opaque, int version_id);
+
static const VMStateDescription vmstate_pflash = {
.name = "pflash_cfi01",
.version_id = 1,
.minimum_version_id = 1,
+ .post_load = pflash_post_load,
.fields = (VMStateField[]) {
VMSTATE_UINT8(wcycle, pflash_t),
VMSTATE_UINT8(cmd, pflash_t),
@@ -982,3 +985,14 @@ MemoryRegion *pflash_cfi01_get_memory(pflash_t *fl)
{
return &fl->mem;
}
+
+static int pflash_post_load(void *opaque, int version_id)
+{
+ pflash_t *pfl = opaque;
+
+ if (!pfl->ro) {
+ DPRINTF("%s: updating bdrv for %s\n", __func__, pfl->name);
+ pflash_update(pfl, 0, pfl->sector_len * pfl->nb_blocs);
+ }
+ return 0;
+}
--
1.8.3.1
next prev parent reply other threads:[~2014-08-23 10:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-23 10:19 [Qemu-devel] [PATCH 0/2] pflash (UEFI varstore) migration shortcut for libvirt Laszlo Ersek
2014-08-23 10:19 ` [Qemu-devel] [PATCH 1/2] pflash_cfi01: fixup stale DPRINTF() calls Laszlo Ersek
2014-08-23 10:19 ` Laszlo Ersek [this message]
2014-08-25 10:33 ` [Qemu-devel] [PATCH 0/2] pflash (UEFI varstore) migration shortcut for libvirt Paolo Bonzini
2014-09-19 6:48 ` Alexey Kardashevskiy
2014-09-19 8:13 ` Paolo Bonzini
2014-08-27 8:58 ` Daniel P. Berrange
2014-08-27 9:21 ` Laszlo Ersek
2014-09-01 15:53 ` Stefan Hajnoczi
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=1408789147-18675-3-git-send-email-lersek@redhat.com \
--to=lersek@redhat.com \
--cc=berrange@redhat.com \
--cc=dgilbert@redhat.com \
--cc=eblake@redhat.com \
--cc=kwolf@redhat.com \
--cc=mprivozn@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=stefanha@redhat.com \
/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).