Re: [edk2-devel] A problem with live migration of UEFI virtual machines

["Laszlo Ersek" <lersek@redhat.com>]

On 02/28/20 05:04, Andrew Fish wrote:

> Maybe I was overcomplicating this. Given your explanation I think the part I'm missing is OVMF is implying FLASH layout, in this split model, based on the size of the OVMF_CODE.fd and OVMF_VARS.fd.  Given that if OVMF_CODE.fd gets bigger the variable address changes from a QEMU point of view. So basically it is the QEMU  API that is making assumptions about the relative layout of the FD in the split model that makes a migration to larger ROM not work.

No, QEMU does not make any assumptions here. QEMU simply grabs both
pflash chips (the order is not random, it can be specified on the
command line -- in fact the QEMU user is expected to specify in the
right order), and then QEMU maps them in decreasing address order from
4GB in guest-phys address space.

If we enlarge OVMF_CODE.fd, then the base address of the varstore
(PcdOvmfFlashNvStorageVariableBase) will sink. That's not a problem per
se, because QEMU doesn't know about PcdOvmfFlashNvStorageVariableBase at
all. QEMU will simply map the varstore, automatically, where the
enlarged OVMF_CODE.fd will look for it.

> Basically the -pflash API does not support changing the size of the ROM without moving NVRAM given the way it is currently defined.

Let me put it like this: the NVRAM gets moved by virtue of how OVMF is
built, and by how QEMU maps the pflash chips into guest-phys address
space. They are in sync, automatically.

The problem is when the NVRAM is internally restructured, or resized --
the new OVMF_CODE.fd binary will reflect this with changed PCDs, and
look for "stuff" at those addresses. But if you still try to use an old
(differently sized, or differently structured) varstore file, while QEMU
will happily map it, parts of the NVRAM will just not end up in places
where OVMF_CODE.fd expects them.

> 
> Given the above it seems like the 2 options are:
> 1) Pad OVMF_CODE.fd to be very large so there is room to grow.

There's already room to grow, *inside* OVMF_CODE.fd. As I've shown
elsewhere in this thread, even the 2MB build has approx. 457 KB free in
the DXEFV volume, even without link-time optimization and without
DEBUG/ASSERT stripping, if you don't enable additional features.

> 2) Add some feature to QUEM that allows the variable store address to not be based on OVMF_CODE.fd size. 

Yes, this has been proposed over time.

It wouldn't help with the case when you change the internal structure of
the NVRAM, and try to run an incompatible OVMF_CODE.fd against that.

> I did see this [1] and combined with your email I either understand, or I'm still confused? :)
> 
> I'm not saying we need to change anything, I'm just trying to make sure I understand how OVMF and QEMU are tied to together. 

I think the most interesting function for you could be
pc_system_flash_map(), in "hw/i386/pc_sysfw.c", in the QEMU source.

> 
> [1] https://www.redhat.com/archives/libvir-list/2019-January/msg01031.html


Thanks
Laszlo