All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>,
	Michal Privoznik <mprivozn@redhat.com>,
	Eric Blake <eblake@redhat.com>,
	"Daniel P. Berrange" <berrange@redhat.com>,
	Kevin Wolf <kwolf@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Juan Quintela <quintela@redhat.com>,
	David Gilbert <dgilbert@redhat.com>,
	qemu devel list <qemu-devel@nongnu.org>,
	David Gibson <david@gibson.dropbear.id.au>,
	Alexey Kardashevskiy <aik@ozlabs.ru>
Subject: Re: [Qemu-devel] [PATCH 0/2] pflash (UEFI varstore) migration shortcut for libvirt
Date: Mon, 25 Aug 2014 12:33:44 +0200	[thread overview]
Message-ID: <53FB1108.6050400@redhat.com> (raw)
In-Reply-To: <1408789147-18675-1-git-send-email-lersek@redhat.com>

Il 23/08/2014 12:19, Laszlo Ersek ha scritto:
> Libvirt is growing support for x86_64 OVMF guests:
> 
> http://www.redhat.com/archives/libvir-list/2014-August/msg01045.html
> 
> An important feature of such guests is the persistent store for
> non-volatile UEFI variables. This is implemented with if=pflash drives.
> The referenced libvirt patchset sets up the varstore files for
> single-host use.
> 
> Wrt. migration, two choices have been considered:
> (a) full-blown live storage migration for the drives backing pflash
>     devices,
> (b) vs. a shortcut that exploits the special nature of pflash drives
>     (namely, their minuscule size, and a RAMBlock that keeps the full
>     contents of each pflash drive visible to the guest, and is
>     up-to-date, at all times.)
> 
> Patch 1/2 is a trivial cleanup (some DPRINTF() calls in pflash_cfi01
> have bit-rotted). Patch 2/2 seeks to implement choice (b), which is what
> the libvirt patchset relies on for migration.
> 
> Thanks,
> Laszlo
> 
> Laszlo Ersek (2):
>   pflash_cfi01: fixup stale DPRINTF() calls
>   pflash_cfi01: write flash contents to bdrv on incoming migration
> 
>  hw/block/pflash_cfi01.c | 18 ++++++++++++++++--
>  1 file changed, 16 insertions(+), 2 deletions(-)
> 

Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>

Alexey/David, I think hw/nvram/spapr_nvram.c should do the same.  It
doesn't have a vmstate, but you can probably use
qemu_add_vm_change_state_handler to the same effect.

Paolo

  parent reply	other threads:[~2014-08-25 10:34 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 ` [Qemu-devel] [PATCH 2/2] pflash_cfi01: write flash contents to bdrv on incoming migration Laszlo Ersek
2014-08-25 10:33 ` Paolo Bonzini [this message]
2014-09-19  6:48   ` [Qemu-devel] [PATCH 0/2] pflash (UEFI varstore) migration shortcut for libvirt 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=53FB1108.6050400@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=aik@ozlabs.ru \
    --cc=berrange@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=dgilbert@redhat.com \
    --cc=eblake@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=lersek@redhat.com \
    --cc=mprivozn@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 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.