Re: New "IndustryStandard" fw_cfg?

[Xiaoyao Li <xiaoyao.li@intel.com>]

On 6/15/2022 8:46 AM, Xu, Min M wrote:
> I would like to add more engineers (Confidential Computing Reviewers in EDK2 community and Intel's QEMU engineers) in this mail thread.
> 
>> -----Original Message-----
>> From: Dionna Amalie Glaze <dionnaglaze@google.com>
>> Sent: Wednesday, June 15, 2022 2:09 AM
>> To: qemu-devel@nongnu.org
>> Cc: Xu, Min M <min.m.xu@intel.com>; Lendacky, Thomas
>> <Thomas.Lendacky@amd.com>
>> Subject: New "IndustryStandard" fw_cfg?
>>
>> 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? 

After re-read and re-think, I think the problem is better to state as: 
we need an interface for QEMU to tell OVMF how much memory it needs to 
accept, from [Minimum to All]. So for the case that user wants to boot 
an partial-enabled confidential VMs (like current Linux TDX and SNP 
guest), user needs to specify from QEMU to tell OVMF to accept all the 
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/Industry
>> Standard/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/58b53669e87fed0d70903e05cd42079
>> fbbdbc195/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/266469947161aa10b1d36843580d36
>> 9d5aa38589/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)