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 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel