Re: New "IndustryStandard" fw_cfg?

[Xiaoyao Li]

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)