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

[Devon Bautista <dbautista@newmexicoconsortium.org>]

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