Re: New "IndustryStandard" fw_cfg?

[Dionna Amalie Glaze]

> > > 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
>
> Ideally no external configuration, although I suspect we need something
> at least temporarily.

Yes, whereas TDX can assume unaccepted memory is supported as part of
its "TDX support" set of capabilities an OS has, SEV-SNP has already
been released and is supported. We therefore need to not break
existing images that "support SEV-SNP".

>
> IMHO the long-term goal should be to make this fully automatic, by
> having efi apps (which includes the linux kernel's efi stub) and
> firmware negotiate this.  Problem is this most likely requires changing
> the uefi specs, which will take a while.
>
> One possible way I see is extending efi boot services with a
> GetMemoryMapEx() call, with an additional flags parameter where the
> caller can specify that it can handle unaccepted memory with a flag
> bit.  When the guest does not set the flag (or uses the old GetMemoryMap
> call) the firmware must accept all memory and return a memory map
> without unaccepted memory.

To allow for future weird memory extensions, I'd recommend this being
a struct with initial size field, but yes.
Sounds like a new UEFI spec would be needed for this negotiation.

>
> > > 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.
>
> New options should use a file path.
>
> See also docs/specs/fw_cfg.txt in qemu source tree.
>

Thanks for this.

> take care,
>   Gerd
>


-- 
-Dionna Glaze, PhD (she/her)