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

["Gerd Hoffmann" <kraxel@redhat.com>]

  Hi,

> * 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.

Matches my understanding.

>   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.

Having separate binaries also simplifies the host-side firmware update,
you can easily update CODE for all guests while the keeping per-guest
VARS file.

> * 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?

Size and mapping location are compile-time constants, I don't think ovmf
talks to the pflash to figure the size.

> * 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.

I think ovmf doesn't care.  It'll be more of an issue for qemu, IIRC the
pflash driver has some code to automagically place code and vars at the
correct location, but that'll require both parts of the firmware being
flash.  Might be easier to teach the pflash device to just map read-only
flash like a rom.

If you don't need persistent vars you can also try "-bios OVMF.fd".

> * 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.

Hmm, isn't that long solved?  IIRC kvm memslots can be configured to
only trap on writes since years.  Or is that something unrelated?

[ Disclaimer: I don't know much about the pflash internals ]

take care,
  Gerd