Re: Runtime configuration methods for OVMF/AAVMF?

Aaron Young

Thanks Laszlo! This is very helpful.

From a user perspective, I was thinking perhaps OVMF/AAVMF could support a generic config file (on the host). Linux users are all too familiar with config files. ;-)

This config file could be passed into OVMF/AAVMF via the "-fw_cfg [name=]<item_name>,file=<path>" mechanism, such as: -fw_cfg name=opt/ovmf/ovmf_config,file=/usr/share/ovmf-x64/OVMF_CONFIG.txt

Contents could be simple name/value pairs (with comments) - each of which associates to values in the code. For example:

# Language.
# Possible values:
# Eng: English
# Fr: Fran├žais
Language Eng

# Boot Menu Wait Timeout (specified in seconds).
# Default is 3 seconds. 0 indicates to skip boot menu.
BootMenuTimeout 5

# Secure Boot Enable/Disable
# Possible Values: Enable, Disable
SecureBoot Disable

# USB Device Enable/Disable
# Possible Values: Enable, Disable
# Default: Enable
# USBDevice Enable

# Debug Log Mask.
# Possible bit mask values:
# DEBUG_INIT 0x00000001 // Initialization
# DEBUG_WARN 0x00000002 // Warnings
# DEBUG_LOAD 0x00000004 // Load events
# DEBUG_FS 0x00000008 // EFI File system
# DEBUG_POOL 0x00000010 // Alloc & Free (pool)
# DEBUG_PAGE 0x00000020 // Alloc & Free (page)
# DEBUG_INFO 0x00000040 // Informational debug messages
# DEBUG_DISPATCH 0x00000080 // PEI/DXE/SMM Dispatchers
# DEBUG_VARIABLE 0x00000100 // Variable
# DEBUG_BM 0x00000400 // Boot Manager
# DEBUG_BLKIO 0x00001000 // BlkIo Driver
# DEBUG_NET 0x00004000 // SNP Driver
# DEBUG_UNDI 0x00010000 // UNDI Driver
# DEBUG_LOADFILE 0x00020000 // LoadFile
# DEBUG_EVENT 0x00080000 // Event messages
# DEBUG_GCD 0x00100000 // Global Coherency Database changes
# DEBUG_CACHE 0x00200000 // Memory range cachability changes
# DEBUG_VERBOSE 0x00400000 // Detailed debug messages that may
# // significantly impact boot performance
# DEBUG_ERROR 0x80000000 // Error
DebugLogMask 0x8040004F

# 64-bit MMIO aperture size (specified in decimal in MB). Default is 32768.
PciMmio64Mb 65536

Of course, these (above) config options are just a few possible/theoretical examples that a user may want to alter via a config file. Many more could be added with time as needs arise and could go well beyond the current possible current options supported via BootManager/HII/Variables/PCDs.

This config file would allow users to a simple way config OVMF/AAVMF prior to first boot and not require knowledge of EDK2 Variables/PCDs, etc.

Perhaps OVMF RPMs could install a "template" config file (similar to the VARS template file) - which has all possible supported options by that version of OVMF/AAVMF commented out(?)

OVMF could parse this file early to populate the values into the code/PCDs/Variables as needed. Each config option would require updates to the code to properly handle the associated config value.

Of course, this brings about the question of whether these value should be transient startup-only values or stored permanently (into the VARS file/variables). Perhaps this could taken on a case-by-case basis what makes best sense for that config option? TBD.

For our specific case, our users would like the ability to enable/disable DEBUG mask flag bits dynamically. Making an OVMF variant for every possible mask value of course is not tenable.

How does this idea strike you?

Thanks again,


Join to automatically receive all group messages.