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 <a...@kernel.org> > Sent: Sunday, January 8, 2023 12:53 AM > To: Yao, Jiewen <jiewen....@intel.com> > Cc: Dov Murik <dovmu...@linux.ibm.com>; devel@edk2.groups.io; > michael.r...@amd.com; Tom Lendacky <thomas.lenda...@amd.com>; Ni, > Ray <ray...@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....@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. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#98354): https://edk2.groups.io/g/devel/message/98354 Mute This Topic: https://groups.io/mt/95815540/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
