Re: How to handle pflash backed OVMF FW upgrade and live migration best?

[Laszlo Ersek <lersek@redhat.com>]

On 03/02/18 13:53, Dr. David Alan Gilbert wrote:
> * Laszlo Ersek (lersek@redhat.com) wrote:
>> CC Dave

>> To give you the simplest example, binaries (and varstores) corresponding
>> to FD_SIZE_2MB and FD_SIZE_4MB are incompatible. If a domain is
>> originally defined on top of an FD_SIZE_2MB OVMF, then it likely cannot
>> be migrated to a host where the same OVMF pathname refers to an
>> FD_SIZE_4MB binary. If you have a mixed environment, then you need to
>> carry both binaries to all hosts (and if you backport fixes from
>> upstream edk2, you need to backport those to both binaries).
>>
>> In addition, assuming the domain is powered down for good (the QEMU
>> process terminates), and you update the domain XML from the FD_SIZE_2MB
>> OVMF binary to the FD_SIZE_4MB binary, you *also* have to
>> delete/recreate the domain's variable store file (losing all UEFI
>> variables the domain has accumulated until then). This is because the
>> FD_SIZE_4MB binary is incompatible with the varstore that was originally
>> created for the FD_SIZE_2MB binary (and vice versa).
> 
> I assume that gives a clear and obvious error message - right?

Unfortunately, no, it doesn't.

The constants that describe the varstore flash location are generated at
build time, and they are cooked into the OVMF binary. Varstore flash
presence is checked / verified, but the flash is not "searched for". In
addition, flash is a pretty early / low-level requirement, so no
display, no serial console etc. So the end result is, you may get a
semi-obscure error message on the QEMU debug port. :( The error message
might vary with what QEMU actually mapped under the addresses that the
OVMF binary expects to belong to the flash chip(s).

Edk2 doesn't really consider "mismatched flash" a condition that can be
handled gracefully; I guess it would be similar to soldering a bad flash
chip to the board and expecting a friendly error message on the PCI
display -- the boot will likely not get that far. ... I'm not defending
the OVMF situation, it is really raw for virt users, and it sucks. :(

Laszlo