On 03/09/18 15:27, Gerd Hoffmann wrote: > 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? I can't judge that. To me all these flags are meaningful. It doesn't hurt to keep them spelled out in the metadata; they don't take much space, they are easy to ignore, and if someone searches for them, they are there. I'll offer an analogy. Sometimes it would be useful to know the full kernel config used on a distro's Live or Installer ISO. Just today I got a question off-list as to whether the aarch64 Fedora 28 Live iso has CONFIG_ARM64_PMEM enabled or not. I have no clue, but this type of question is not far from the domain of "libosinfo" (which basically tells you what OS release has drivers for what devices). Is "libfwinfo" such a stretch? Maybe. :) So, whether this level of detail is useful to end-users and/or management applications, I cannot tell; I just wanted to expose the "current spectrum" (for OVMF and ArmVirtQemu) in reasonable detail. Thanks Laszlo -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
