Re: [Qemu-devel] [RFC] Defining firmware (OVMF, et al) metadata format & file

[Gerd Hoffmann <kraxel@redhat.com>]

  Hi,

> For OVMF (x86), I guess the initial set of properties should come from
> the "-D FOO[=BAR]" build flags that OVMF currently supports. (The list
> might grow or change incompatibly over time, so this is just a raw
> starter idea.)

> (0) ARCH (one of IA32, IA32X64, X64) -- the bitnesses of the PEI and DXE
> phases of the firmware.
> 
> IA32 stands for "32-bit PEI and DXE". Such firmware is usable for
> booting 32-bit OSes only, and runs on both qemu-system-i386 and
> qemu-system-x86_64.
> 
> IA32X64 stands for "32-bit PEI, 64-bit DXE". Needs qemu-system-x86_64
> and runs 64-bit OSes only.
> 
> X64 stands for "64-bit PEI and DXE". Needs qemu-system-x86_64 and runs
> 64-bit OSes only.

I'd simply put that info the 'arch' bucket.  IA32 gets 'i386' (assuming
we simply use qemu target names), IA32X64 + X64 get 'x86_64'.

> (1) SECURE_BOOT_ENABLE (boolean) -- whether the Secure Boot UEFI feature
> is built into the firmware image.

Probably useful for upper management (above libvirt), for enabling
secure boot key enrollment etc. in the UI.

> (2) SMM_REQUIRE (boolean) -- whether the SMM driver stack is included in
> the firmware.

Needed (libvirt must enable smm).

> (3) HTTP_BOOT_ENABLE (boolean) -- whether UEFI HTTP boot is available in
> the firmware image, in addition to the default PXE boot.

> (4) TLS_ENABLE (boolean) -- configurable independently of
> HTTP_BOOT_ENABLE, but only really makes sense in combination.

> (5) NETWORK_IP6_ENABLE (boolean) -- determines whether IPv6 support is
> available.

Do we actually need formal flags for these?  Which application would
use them?

For humans this can go into the freeform "description" text field.

> (6) FD_SIZE_IN_KB (one of: 1024, 2048, 4096) -- the size of the combined
> firmware image (executable portion and variable store together), in KB.

Hmm, dunno.  Might be useful as varstores are not portable between
builds of different sizes, so libvirt could use this for sanity checks.

> (7) DEBUG_ON_SERIAL_PORT (boolean) -- whether OVMF sends its debug
> messages to the QEMU debug IO port, or to the serial port.

> (8) SOURCE_DEBUG_ENABLE (boolean) -- whether OVMF includes the edk2
> debug agent that allows it to be debugged from a proprietary debugger
> program, likely connected via the emulated serial port.

> (9) CSM_ENABLE (boolean) -- whether OVMF includes traditional BIOS
> support, by including the SeaBIOS Compatibility Support Module.

Same question as for 3+4+5: Do we really need those?

> Given that the SeaBIOS CSM itself can be built with various
> configurations, it might make sense to list further properties when this
> property is enabled.

I doubt this is useful, established practice is that people just use
seabios directly instead if using the ovmf+csm combo.

> (10) E1000_ENABLE (boolean) -- whether OVMF includes the
> non-redistributable, binary only E1000(E) UEFI driver module from Intel
> (previously known as "PROEFI", more recently known as "BootUtil").

> (11) USE_OLD_SHELL (boolean) -- whether the UEFI shell implementation
> built into OVMF is the old (EDK1 / EFI-1 style) shell which lives in a
> separate repository, or the new (EDK2 / UEFI-2 style) shell which lives
> within the edk2 project.

> (12) TOOLCHAIN (string): the edk2 toolchain identifier with which the
> firmware was built.

> (13) TARGET (one of NOOPT, DEBUG, RELEASE) -- the target for which the
> firmware image was built.

Same question as for 3+4+5+7+8+9: Do we really need those?

> For ArmVirt, we have:
> 
> (12) ARCH (one of ARM and AARCH64) -- 32-bit / 64-bit distinction.

Likewise just use arch.

> (17) Well, what do I call this, let's call it ENTRY_POINT (one of Qemu,
> QemuKernel, Xen).
> 
> This distinguishes what VMM the ArmVirt firmware was built for, and for
> QEMU, it also distinguishes "boot from flash" (Qemu) or "boot as payload
> for another, earlier boot firmware" (QemuKernel).

Hmm, that looks simliar to u-boot, which I think can also be build as
both flash image and kernel image (loadable via -kernel).  So I guess we
want that one, as how-to-load-this-blob option (-bios vs -pflash vs -kernel).

cheers,
  Gerd