Re: [Qemu-devel] [PATCH 0/2] pflash (UEFI varstore) migration shortcut for libvirt

[Alexey Kardashevskiy <aik@ozlabs.ru>]

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 <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.

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