OVMF dynamic NVRAM size discovering

OVMF dynamic NVRAM size discovering

[Denis Plotnikov]

Hello!

I'd like to ask whether it's a good idea or not to make the omfv
discover the variable image size in the runtime.

We have a setting in our product to use separate pflash images for OVMF
code and variables parts in QEMU/KVM based virtual machines.
Currently, we use a 2M code image but want to switch to using a 4M ones
to extend the variable values storage, because of Windows certification
requirements.

We think of adding an ability to OVFM to discover the size of the 
variable part
dynamically.

It could work like the following:
1. teach qemu to provide the size of pflash0 and pflash1 via fw_cfg
2. modify OVMF in order to discover the variable size part dynamically 
via fw_cfg and adjust the OVMF's inner parameters accordingly

We have some concerns about our understanding of OVMF and would like to 
ask to
evaluate the approach suggested.
Is it feasible? Do we miss something?

-- 
Best,
Denis

Re: OVMF dynamic NVRAM size discovering

[Laszlo Ersek]

On 07/11/18 15:01, Denis Plotnikov wrote:
> Hello!
> 
> I'd like to ask whether it's a good idea or not to make the omfv
> discover the variable image size in the runtime.

Not a good idea.

> We have a setting in our product to use separate pflash images for OVMF
> code and variables parts in QEMU/KVM based virtual machines.

That's a good choice.

> Currently, we use a 2M code image but want to switch to using a 4M ones
> to extend the variable values storage, because of Windows certification
> requirements.

That's correct.

You will have to abandon the existent variable store files (for existent
VMs), and recreate them from the new variable store template file that
comes from the 4MB build, when you switch the firmware binary from the
2MB build to the 4MB build.

In other words, you can switch an (offline) VM from one firmware binary
to another, but at the same time you have to recreate the variable store
for the VM from the pristine variable store template that comes from the
new (4MB unified) firmware build. For example, OVMF_CODE.fd from the 2MB
build, and a variable store file instantiated from OVMF_VARS.fd from the
4MB build, are not compatible. Vice versa for 4MB/2MB.

If you can't recreate varstore files like this, then you can only
provide the new (4MB unified) firmware build *in addition* to the other
firmware build, and only newly created domains will be able to use it.

> We think of adding an ability to OVFM to discover the size of the
> variable part dynamically.
> 
> It could work like the following:
> 1. teach qemu to provide the size of pflash0 and pflash1 via fw_cfg
> 2. modify OVMF in order to discover the variable size part dynamically
> via fw_cfg and adjust the OVMF's inner parameters accordingly
> 
> We have some concerns about our understanding of OVMF and would like to
> ask to evaluate the approach suggested.
> Is it feasible? Do we miss something?

In general, using fw_cfg files for setting dynamic PCDs, is a widely
used technique.

In this particular case, it's not feasible, to my understanding.

- There are several build constants related to the internal structure of
the pflash chip in question -- basically that chip is subdivided into
multiple areas. Knowing the outermost size is insufficient.

- The variable store template file is prepared at build, and it depends
on -- and can't avoid open-coding -- some of those lower-level constants.

- As much as I dislike it, OVMF still contains support for the "-bios"
QEMU option (when there is no pflash at all). That complicates things in
obscure and unpleasant ways.

Clearly, I can't "guarantee" that the idea is impossible to implement.
However, it does make me *really* uncomfortable.

I strongly suggest going statically with the 4MB build, and tracking the
firmware choice explicitly, both in your host package system, and at the
domain level, in your virtualization management product.

In case you use libvirt as a building block for that, libvirt already
supports this.

See also QEMU commit 3a0adfc9bfcf ("docs/interop: add "firmware.json"",
2018-06-01).

Thanks,
Laszlo