On 08/25/2014 08:33 PM, Paolo Bonzini wrote: > 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 <pbonz...@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.
I am not sure I understood the proposal correctly. Right now we use NVRAM on sPAPR as: -drive id=id3,if=none,file=qemu_nvram.img -global spapr-nvram.drive=id3 So the NVRAM file is BlockDriverState and HMP's "migrate -b" copies the content just fine. What is missing here? Thanks. -- Alexey
