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

["Yao, Jiewen" <jiewen.yao@intel.com>]

Never mind. I don’t have concern for SEV code.

You may merge it, if you think it is OK.


> -----Original Message-----
> From: Ard Biesheuvel <ardb@kernel.org>
> Sent: Sunday, January 8, 2023 12:53 AM
> To: Yao, Jiewen <jiewen.yao@intel.com>
> Cc: Dov Murik <dovmurik@linux.ibm.com>; devel@edk2.groups.io;
> Michael.Roth@amd.com; Tom Lendacky <thomas.lendacky@amd.com>; Ni,
> Ray <ray.ni@intel.com>
> Subject: Re: [edk2-devel] [PATCH 1/4] OvmfPkg/AmdSevDxe: Allocate SEV-
> SNP CC blob as EfiACPIReclaimMemory
> 
> 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.