Hi y'all, I'm Dionna. I work on Confidential VMs at Google Cloud. I've been keeping up with the TDX and SEV-SNP developments in OVMF and Linux, and some in Qemu.
There's a new UEFI feature in v2.9 of the specification (March 2021) that allows for memory ranges to be classified as "unaccepted", since both TDX and SEV-SNP require that the guest VM accept any host-made changes to page state. We should expect newer technologies on non-x86 architectures to require memory acceptance as well. Operating systems are not necessarily going to support this memory type, however. This leads to a problem: how does the UEFI know that the OS it's going to boot will support unaccepted memory? Right now we (Google Compute Engine) have a system of "tagging" for guest image providers to state that their OS supports some new feature so that we can enable appropriate configurations for certain images. I could go about adding a Google-specific fw_cfg file path and definition to tell our custom OVMF build to use unaccepted memory or not, but I personally prefer open source. I don't know y'all's process though, so I'm asking before making a patch set. There are two approaches I've considered. 1. An arch-specific config key for a u64 value: The idea would be that I would add QemuFwCfgItemUnacceptedMinimum = 0x8005 here https://github.com/tianocore/edk2/blob/master/OvmfPkg/Include/IndustryStandard/QemuFwCfg.h#L50 For Qemu, the main code I see for adding config is here, but I'm not sure what y'all's preferred external configuration method is to get a value from an invocation (flag, config file, etc) to fw_cfg.c: https://github.com/qemu/qemu/blob/58b53669e87fed0d70903e05cd42079fbbdbc195/hw/i386/fw_cfg.c#L95 We'd add something like fw_cfg_add_u64(fw_cfg, FW_CFG_MINIMUM_ACCEPTED_MEMORY_SIZE, ms->minimum_accepted_memory_size); where FW_CFG_MINIMUM_ACCEPTED_MEMORY_SIZE is #defined as FW_CFG_ARCH_LOCAL + 5 in https://github.com/qemu/qemu/blob/266469947161aa10b1d36843580d369d5aa38589/hw/i386/fw_cfg.h The name has "minimum" in it since the firmware can choose to accept more than the minimum, and specifically interpret 0 as UINT64_MAX. 2. A "well-known" file path to be included in the file slots starting at 0x0020, such as "etc/min_accepted_mem_size", still plumbed through like in 1. Thanks! -- -Dionna Glaze, PhD (she/her)
