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

["Philippe Mathieu-Daudé" <philmd@redhat.com>]

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/


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.

> Since QEMU commit 0657c65 (hw/i386/pc:
> add max combined fw size as machine configuration option), QEMU supports
> flash sizes up to 16MiB using the "max-fw-size" property.
> 
> This new 16MiB flash size uses the same non-volatile variable store size
> and layout as the default 4MiB flash size to ensure compatibility when
> switching to the larger flash size. Since the 4MiB target was created in
> commit b24fca0 (OvmfPkg: introduce 4MB flash image (mainly) for Windows
> HCK), the variable store size increased by 200KiB to 256KiB, which
> should provide an adequate safety margin.