Re: [edk2-devel] [PATCH 1/4] OvmfPkg/AmdSevDxe: Allocate SEV-SNP CC blob as EfiACPIReclaimMemory

["Ard Biesheuvel" <ardb@kernel.org>]

On Sat, 7 Jan 2023 at 03:01, Yao, Jiewen <jiewen.yao@intel.com> wrote:
>
> Hi Dov/Ard
> Please allow me to clarify:
>
> EfiACPIReclaimMemory in UEFI spec means: OS may use the memory, after it copies the ACPI table to its own location. It is also called "AddressRangeACPI" in ACPI spec.
>
> [2] https://uefi.org/specs/ACPI/6.5/15_System_Address_Map_Interfaces.html, search AddressRangeACPI.
> [3] https://uefi.org/specs/UEFI/2.10/07_Services_Boot_Services.html, search EfiACPIReclaimMemory.
>
> However, in the description, you mentioned "The SEV-SNP Confidential Computing blob contains metadata that should remain accessible for the life of the guest."
> That requirement conflicts with the definition of ACPIReclaim memory.
>
> I would like to suggest either of below, to meet the need "that should remain accessible for the life of the guest."
> a) EfiACPIMemoryNVS in UEFI, also known as AddressRangeNVS in ACPI (or)
> b) EfiReservedMemoryType in UEFI, also knowns as AddressRangeReserved in ACPI.
>
> Please double confirm that.
>

If EfiACPIMemoryNVS is considered more appropriate, I don't have any
issues with that.

But the patch is correct in the sense that it should not use
statically allocated objects. And EfiRuntimeServicesData should be
avoided as well (athough it is often used for cases like this) as it
will end up getting mapped into the firmware page tables for no
reason.

EfiReservedMemory is not suitable for this - Linux on ARM must omit
this from all its mappings of system memory, because the OS does not
know *why* it is reserved and with which attributes it is being
mapped, and the architecture does not tolerate duplicate mappings with
mismatched attributes.

The semantics of EfiAcpiReclaimMemory are also suitable for cases
where the contents of the region is only relevant to the OS, and not
to the firmware itself, and it is really up to the OS to decided
whether or not it will reclaim the region in question. So for passing
tables in memory that are similar in purpose to ACPI tables (i.e.,
describe the platform to the OS), EfiAcpiReclaimMemory is suitable
imho.