Re: [PATCH v2 1/1] OvmfPkg: Introduce 16MiB flash size for (primarily) Linuxboot


Devon Bautista <dbautista@...>
 

On 9/9/21 03:09, Philippe Mathieu-Daudé wrote:
On 9/3/21 7:26 AM, Devon Bautista wrote:
The largest size flash image currently available for OVMF builds, 4MiB,
is too small to insert a Linux kernel and initramfs into the DXEFV, and
is thus insufficient for testing Linuxboot builds via OVMF.

Introduce the FD_SIZE_16MB build macro (equivalently,
FD_SIZE_IN_KB=16384), which enlarges the full flash image to 16MiB, the
maximum size available for x86.
I understand this is unavoidable to remove the restriction, but this
will have a negative impact on clouds memory consumption. ARM clouds
are already suffering from having 64MiB flashes, see:
https://lore.kernel.org/all/20201116104216.439650-1-david.edmondson@oracle.com/
Is ARM still padding flash images with zeros up to 64MB?

Even so, this patch merely introduces the 16MB macro but does not make it the default. Genuinely, I am wondering how having this optional build macro would conflict with ARM's memory consumption if ARM is already using the default 4MB build target for OVMF, unless ARM is already using a 16MB build target downstream and this would conflict with that.
Some notes to extend the discussion.
* Why is QEMU using 2 flashes (CODE & DATA)?
My historical understanding is when OVMF was started, QEMU flash
model was not supporting sector/bank (write/erase) protection.
OVMF requirements were:
- CODE section ("secure", not modifiable by the guest)
- DATA section (modifiable)
The easier way to get the CODE secure is to use different devices,
one enforced in "read-only" mode.
Being a firmware for virtualized guests, it makes no sense to have
the guest upgrade the CODE: it is error-prone, and cheaper to do
directly on the host, rebooting the guest.
* Why not use a ROM for the CODE section and flash for the DATA one?
This is not clear to me. I suppose the firmware wanted to be able
to poll the hardware size, and the pflash allow that with CFI I/O
requests?
* Could we replace the CODE pflash by a ROM device?
QEMU provides the -fw_cfg device and versioned machines. To the best
of my knowledge it seems doable, with careful modifications in OVMF
and ArmVirt.
* What are the benefits of using a ROM for the CODE section?
- simpler code path, simpler to audit / review, safer
- reduce migration burden (no pflash device state)
- reduce memory consumption (backing file mmaped with MAP_SHARED)
* Is there similar problems with DATA section?
The biggest problem is the memory waste, the pflash model was
designed to be executable, modifiable, and as fast as possible
(for execution). This is achieved by copying the whole flash
content in an internal buffer. For DATA flash this is no speed
gain but high memory penalty.
* Can the DATA section memory consumption be reduced?
Yes, various suggestions were posted on QEMU mailing list, but
nothing accepted so far, this is still a work in progress, and
ideas are welcomed.
I'm unsure I have the experience necessary to make an informed comment on these points; I think Gerd and/or the other OVMF maintainers/reviewers would have better insight.

Best,
Devon

Join devel@edk2.groups.io to automatically receive all group messages.