> > > 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)
