From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web11.24565.1673110367755897030 for ; Sat, 07 Jan 2023 08:52:47 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=tSpLmjnR; spf=pass (domain: kernel.org, ip: 139.178.84.217, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id D8BAF60B36 for ; Sat, 7 Jan 2023 16:52:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4CCA8C433D2 for ; Sat, 7 Jan 2023 16:52:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1673110366; bh=btS9+/cMxVqLGACZ07pn6NOmkuJGxKQYrNP/AI5ekM0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=tSpLmjnR7CxMx6JSSHZovxQaiecnqCFBzLZmLGw4RuslRPtxUVtj9MK0AFAQlRlCC SoCVCTMm15L00hIShBya8bP1JL1tsunmHrnpjSGnChhUukxAgDkCqSpJ8Rv88GnH9z /P4eYbAhNLbEbuvDpqiz435zkwbmnfiP76Quqfams9Pyv2HOOZ05Ryu9LY+jyiZfTY Ae1kyFSILRDG8DoDUyyTARfN/03tpzGyipiR+NUq1NGcicY40EJAtCMQUC0lhnJ4t1 uWJ1bLgbtu2/mpVzEyqt6WArI6UeH6KBp6pi046xAd3QSPJEwydIoBjtmo99X4GQrW bWMDX+fOK1Smw== Received: by mail-lf1-f43.google.com with SMTP id bq39so6472415lfb.0 for ; Sat, 07 Jan 2023 08:52:46 -0800 (PST) X-Gm-Message-State: AFqh2kqZ3Il8ZsTIuUQykssxIlPyrQDFtmWTZ4UZX0mnICREor+rrdU0 LJCdTV5NMkff9xad6ELBlsr35xhuYwm+twJvBIU= X-Google-Smtp-Source: AMrXdXuLYkrOC6nWB/NtRi3ZRHtOVdmqf/7OvhZPcKf2Lx80u6+OM0Jq0rGL8aP97MQlE3X+ynacWSDl8ax1e7AjWhU= X-Received: by 2002:ac2:5d4e:0:b0:4b5:964d:49a4 with SMTP id w14-20020ac25d4e000000b004b5964d49a4mr5076882lfd.637.1673110364339; Sat, 07 Jan 2023 08:52:44 -0800 (PST) MIME-Version: 1.0 References: <20221221160651.182143-1-michael.roth@amd.com> <20221221160651.182143-2-michael.roth@amd.com> In-Reply-To: From: "Ard Biesheuvel" Date: Sat, 7 Jan 2023 17:52:32 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH 1/4] OvmfPkg/AmdSevDxe: Allocate SEV-SNP CC blob as EfiACPIReclaimMemory To: "Yao, Jiewen" Cc: Dov Murik , "devel@edk2.groups.io" , "Michael.Roth@amd.com" , Tom Lendacky , "Ni, Ray" Content-Type: text/plain; charset="UTF-8" On Sat, 7 Jan 2023 at 03:01, Yao, Jiewen 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.