MdeModulePkg/Core/Dxe/DxeMain.inf | 1 + MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c | 6 + MdePkg/Include/Guid/EventGroup.h | 5 + MdePkg/Include/Protocol/MemoryAcceptance.h | 40 +++++ MdePkg/MdePkg.dec | 8 +- OvmfPkg/AmdSev/AmdSevX64.dsc | 1 + OvmfPkg/AmdSev/AmdSevX64.fdf | 1 + OvmfPkg/AmdSevDxe/AmdSevDxe.c | 55 ++++++- OvmfPkg/AmdSevDxe/AmdSevDxe.inf | 3 + OvmfPkg/CocoDxe/CocoDxe.c | 174 ++++++++++++++++++++ OvmfPkg/CocoDxe/CocoDxe.inf | 46 ++++++ OvmfPkg/IntelTdx/IntelTdxX64.dsc | 1 + OvmfPkg/IntelTdx/IntelTdxX64.fdf | 1 + OvmfPkg/Library/BaseMemEncryptSevLib/X64/DxeSnpSystemRamValidate.c | 24 ++- OvmfPkg/OvmfPkgIa32X64.dsc | 1 + OvmfPkg/OvmfPkgIa32X64.fdf | 1 + OvmfPkg/OvmfPkgX64.dsc | 1 + OvmfPkg/OvmfPkgX64.fdf | 1 + OvmfPkg/PlatformPei/AmdSev.c | 5 + 19 files changed, 366 insertions(+), 9 deletions(-) create mode 100644 MdePkg/Include/Protocol/MemoryAcceptance.h create mode 100644 OvmfPkg/CocoDxe/CocoDxe.c create mode 100644 OvmfPkg/CocoDxe/CocoDxe.inf
These seven patches build on the lazy-accept patch series "Introduce Lazy-accept for Tdx guest" by adding SEV-SNP support for the MemoryAccept protocol, and importantly making eager memory acceptance the default behavior. We implement a standardized event group from UEFI v2.9, EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SERVICES, since it provides exactly the right invocation point for eagerly accepting memory if eager acceptance has not been disabled. To make use of this event group, we add a new driver that is meant to carry behavior that is needed for all confidential compute technologies, not just specific platforms, CocoDxe. In CocoDxe we implement the default safe behavior to accept all unaccepted memory and invalidate the MemoryMap on ExitBootServices. To allow the OS loader to prevent the eager acceptance, we add a new protocol, up for standardization, AcceptAllUnacceptedMemoryProtocol. This protocol has one interface, Disable(). The OS loader can inform the UEFI that it supports the unaccepted memory type and accepts the responsibility to accept it. All images that support unaccepted memory must now locate and call this new BZ3987_ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL and call the Disable function. Changes since v7: - Rebased onto lazy accept v4 patch series, so memory accept protocol has the EDKII prefix, and the unaccepted memory type has the BZ3937 prefix. - Removed a bad #include to a header removed in v7. - Renamed the protocol to BZ3987_MEMORY_ACCEPTANCE_PROTOCOL as per the discussion on the buganizer issue. - Uncrustify formatting Changes since v6: - Added implementation of EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SERVICES. - Changed callback protocol of v5 to instead use the standardized event group for before_exit_boot_services. Changes since v5: - Generic callback protocol moved to MdeModulePkg - Removed use of EFI_WARN_STALE_DATA and added comment that the callback should only return EFI_SUCCESS or EFI_INVALID_PARAMETER. - Removed errant log statement and fixed formatting. Changes since v4: - Commit message wording - Replaced direct change to DxeMain with a more generic callback protocol. - Implemented the direct change as an instance of the callback protocol from a new CocoDxe driver. - Replaced "enable" protocol with a "disable" protocol, since the name was confusing. The AcceptAllUnacceptedMemory protocol directly names the behavior that is disabling. Changes since v3: - "DxeMain accepts all memory" patch split into 3 to make each patch affect only one package at a time. Changes since v2: - Removed the redundant memory accept interface and added the accept behavior to the DXE implementation of MemEncryptSevSnpPreValidateSystemRam. - Fixed missing #include in >=4GB patch. Changes since v1: - Added a patch to classify SEV-SNP memory above 4GB unaccepted. - Fixed style problems in EfiMemoryAcceptProtocol implementation. Cc: Ard Biescheuvel <ardb@kernel.org> Cc: "Min M. Xu" <min.m.xu@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Tom Lendacky <Thomas.Lendacky@amd.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Andrew Fish <afish@apple.com> Cc: "Michael D. Kinney" <michael.d.kinney@intel.com> Signed-off-by: Dionna Glaze <dionnaglaze@google.com> Dionna Glaze (7): OvmfPkg: Realize EfiMemoryAcceptProtocol in AmdSevDxe MdePkg: Add EFI_EVENT_BEFORE_EXIT_BOOT_SERVICES_GUID MdeModulePkg: Notify BeforeExitBootServices in CoreExitBootServices OvmfPkg: Introduce CocoDxe driver MdePkg: Introduce the MemoryAcceptance protocol OvmfPkg: Implement AcceptAllUnacceptedMemory in CocoDxe OvmfPkg/PlatformPei: SEV-SNP make >=4GB unaccepted MdeModulePkg/Core/Dxe/DxeMain.inf | 1 + MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c | 6 + MdePkg/Include/Guid/EventGroup.h | 5 + MdePkg/Include/Protocol/MemoryAcceptance.h | 40 +++++ MdePkg/MdePkg.dec | 8 +- OvmfPkg/AmdSev/AmdSevX64.dsc | 1 + OvmfPkg/AmdSev/AmdSevX64.fdf | 1 + OvmfPkg/AmdSevDxe/AmdSevDxe.c | 55 ++++++- OvmfPkg/AmdSevDxe/AmdSevDxe.inf | 3 + OvmfPkg/CocoDxe/CocoDxe.c | 174 ++++++++++++++++++++ OvmfPkg/CocoDxe/CocoDxe.inf | 46 ++++++ OvmfPkg/IntelTdx/IntelTdxX64.dsc | 1 + OvmfPkg/IntelTdx/IntelTdxX64.fdf | 1 + OvmfPkg/Library/BaseMemEncryptSevLib/X64/DxeSnpSystemRamValidate.c | 24 ++- OvmfPkg/OvmfPkgIa32X64.dsc | 1 + OvmfPkg/OvmfPkgIa32X64.fdf | 1 + OvmfPkg/OvmfPkgX64.dsc | 1 + OvmfPkg/OvmfPkgX64.fdf | 1 + OvmfPkg/PlatformPei/AmdSev.c | 5 + 19 files changed, 366 insertions(+), 9 deletions(-) create mode 100644 MdePkg/Include/Protocol/MemoryAcceptance.h create mode 100644 OvmfPkg/CocoDxe/CocoDxe.c create mode 100644 OvmfPkg/CocoDxe/CocoDxe.inf -- 2.38.0.135.g90850a2211-goog -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#95525): https://edk2.groups.io/g/devel/message/95525 Mute This Topic: https://groups.io/mt/94544528/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On 10/24/22 15:41, Dionna Glaze wrote: > These seven patches build on the lazy-accept patch series > > "Introduce Lazy-accept for Tdx guest" Since the above series was accepted into the EDK2 tree, can this series also be pulled in so that both TDX and SNP can support unaccepted memory in the same release? Thanks, Tom > > by adding SEV-SNP support for the MemoryAccept protocol, and > importantly making eager memory acceptance the default behavior. > > We implement a standardized event group from UEFI v2.9, > EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SERVICES, since it provides exactly > the right invocation point for eagerly accepting memory if eager > acceptance has not been disabled. > > To make use of this event group, we add a new driver that is meant to > carry behavior that is needed for all confidential compute technologies, > not just specific platforms, CocoDxe. In CocoDxe we implement the > default safe behavior to accept all unaccepted memory and invalidate > the MemoryMap on ExitBootServices. > > To allow the OS loader to prevent the eager acceptance, we add a new > protocol, up for standardization, AcceptAllUnacceptedMemoryProtocol. > This protocol has one interface, Disable(). The OS loader can inform the > UEFI that it supports the unaccepted memory type and accepts the > responsibility to accept it. > > All images that support unaccepted memory must now locate and call this > new BZ3987_ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL and call the Disable > function. > > Changes since v7: > - Rebased onto lazy accept v4 patch series, so memory accept protocol > has the EDKII prefix, and the unaccepted memory type has the BZ3937 > prefix. > - Removed a bad #include to a header removed in v7. > - Renamed the protocol to BZ3987_MEMORY_ACCEPTANCE_PROTOCOL as per the > discussion on the buganizer issue. > - Uncrustify formatting > > Changes since v6: > - Added implementation of EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SERVICES. > - Changed callback protocol of v5 to instead use the standardized event > group for before_exit_boot_services. > > Changes since v5: > - Generic callback protocol moved to MdeModulePkg > - Removed use of EFI_WARN_STALE_DATA and added comment that the callback > should only return EFI_SUCCESS or EFI_INVALID_PARAMETER. > - Removed errant log statement and fixed formatting. > > Changes since v4: > - Commit message wording > - Replaced direct change to DxeMain with a more generic callback > protocol. > - Implemented the direct change as an instance of the callback protocol > from a new CocoDxe driver. > - Replaced "enable" protocol with a "disable" protocol, since the name > was confusing. The AcceptAllUnacceptedMemory protocol directly names > the behavior that is disabling. > > Changes since v3: > - "DxeMain accepts all memory" patch split into 3 to make each patch > affect only one package at a time. > > Changes since v2: > - Removed the redundant memory accept interface and added the accept > behavior to the DXE implementation of > MemEncryptSevSnpPreValidateSystemRam. > - Fixed missing #include in >=4GB patch. > > Changes since v1: > - Added a patch to classify SEV-SNP memory above 4GB unaccepted. > - Fixed style problems in EfiMemoryAcceptProtocol implementation. > > Cc: Ard Biescheuvel <ardb@kernel.org> > Cc: "Min M. Xu" <min.m.xu@intel.com> > Cc: Gerd Hoffmann <kraxel@redhat.com> > Cc: James Bottomley <jejb@linux.ibm.com> > Cc: Tom Lendacky <Thomas.Lendacky@amd.com> > Cc: Jiewen Yao <jiewen.yao@intel.com> > Cc: Erdem Aktas <erdemaktas@google.com> > Cc: Andrew Fish <afish@apple.com> > Cc: "Michael D. Kinney" <michael.d.kinney@intel.com> > > Signed-off-by: Dionna Glaze <dionnaglaze@google.com> > > Dionna Glaze (7): > OvmfPkg: Realize EfiMemoryAcceptProtocol in AmdSevDxe > MdePkg: Add EFI_EVENT_BEFORE_EXIT_BOOT_SERVICES_GUID > MdeModulePkg: Notify BeforeExitBootServices in CoreExitBootServices > OvmfPkg: Introduce CocoDxe driver > MdePkg: Introduce the MemoryAcceptance protocol > OvmfPkg: Implement AcceptAllUnacceptedMemory in CocoDxe > OvmfPkg/PlatformPei: SEV-SNP make >=4GB unaccepted > > MdeModulePkg/Core/Dxe/DxeMain.inf | 1 + > MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c | 6 + > MdePkg/Include/Guid/EventGroup.h | 5 + > MdePkg/Include/Protocol/MemoryAcceptance.h | 40 +++++ > MdePkg/MdePkg.dec | 8 +- > OvmfPkg/AmdSev/AmdSevX64.dsc | 1 + > OvmfPkg/AmdSev/AmdSevX64.fdf | 1 + > OvmfPkg/AmdSevDxe/AmdSevDxe.c | 55 ++++++- > OvmfPkg/AmdSevDxe/AmdSevDxe.inf | 3 + > OvmfPkg/CocoDxe/CocoDxe.c | 174 ++++++++++++++++++++ > OvmfPkg/CocoDxe/CocoDxe.inf | 46 ++++++ > OvmfPkg/IntelTdx/IntelTdxX64.dsc | 1 + > OvmfPkg/IntelTdx/IntelTdxX64.fdf | 1 + > OvmfPkg/Library/BaseMemEncryptSevLib/X64/DxeSnpSystemRamValidate.c | 24 ++- > OvmfPkg/OvmfPkgIa32X64.dsc | 1 + > OvmfPkg/OvmfPkgIa32X64.fdf | 1 + > OvmfPkg/OvmfPkgX64.dsc | 1 + > OvmfPkg/OvmfPkgX64.fdf | 1 + > OvmfPkg/PlatformPei/AmdSev.c | 5 + > 19 files changed, 366 insertions(+), 9 deletions(-) > create mode 100644 MdePkg/Include/Protocol/MemoryAcceptance.h > create mode 100644 OvmfPkg/CocoDxe/CocoDxe.c > create mode 100644 OvmfPkg/CocoDxe/CocoDxe.inf > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#96078): https://edk2.groups.io/g/devel/message/96078 Mute This Topic: https://groups.io/mt/94544528/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
Hi Tom/Dionna I think this patch is addressing https://bugzilla.tianocore.org/show_bug.cgi?id=3987. For patch 1~3, I am OK for the API which we already agreed, such as EfiMemoryAcceptProtocol and EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SERVICES. I have given Acked by: Jiewen Yao <Jiewen.yao@intel.com> For patch 4, it changed the behavior to accept all. I don’t believe it should be 4. It should be the latest one. (please correct me if I am wrong.) For patch 5~6, I cannot give R-B for BZ3987_MEMORY_ACCEPTANCE_PROTOCAL proposed here because it does not address my concern. Please refer to the discussion in the Bugzilla. If you want to split the patch series and submit 1~3 as standalone one, that will match SEV to TDX on lazy accept part. I believe we may merge them after we get R-B from right person. Thank you Yao, Jiewen > -----Original Message----- > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of > Lendacky, Thomas via groups.io > Sent: Tuesday, November 8, 2022 10:38 PM > To: Dionna Glaze <dionnaglaze@google.com>; devel@edk2.groups.io > Cc: Ard Biescheuvel <ardb@kernel.org>; Xu, Min M <min.m.xu@intel.com>; > Gerd Hoffmann <kraxel@redhat.com>; James Bottomley > <jejb@linux.ibm.com>; Yao, Jiewen <jiewen.yao@intel.com>; Aktas, Erdem > <erdemaktas@google.com>; Andrew Fish <afish@apple.com>; Kinney, > Michael D <michael.d.kinney@intel.com> > Subject: Re: [edk2-devel] [PATCH v8 0/7] Add safe unaccepted memory > behavior > > On 10/24/22 15:41, Dionna Glaze wrote: > > These seven patches build on the lazy-accept patch series > > > > "Introduce Lazy-accept for Tdx guest" > > Since the above series was accepted into the EDK2 tree, can this series > also be pulled in so that both TDX and SNP can support unaccepted > memory > in the same release? > > Thanks, > Tom > > > > > by adding SEV-SNP support for the MemoryAccept protocol, and > > importantly making eager memory acceptance the default behavior. > > > > We implement a standardized event group from UEFI v2.9, > > EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SERVICES, since it provides > exactly > > the right invocation point for eagerly accepting memory if eager > > acceptance has not been disabled. > > > > To make use of this event group, we add a new driver that is meant to > > carry behavior that is needed for all confidential compute technologies, > > not just specific platforms, CocoDxe. In CocoDxe we implement the > > default safe behavior to accept all unaccepted memory and invalidate > > the MemoryMap on ExitBootServices. > > > > To allow the OS loader to prevent the eager acceptance, we add a new > > protocol, up for standardization, AcceptAllUnacceptedMemoryProtocol. > > This protocol has one interface, Disable(). The OS loader can inform the > > UEFI that it supports the unaccepted memory type and accepts the > > responsibility to accept it. > > > > All images that support unaccepted memory must now locate and call > this > > new BZ3987_ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL and call > the Disable > > function. > > > > Changes since v7: > > - Rebased onto lazy accept v4 patch series, so memory accept protocol > > has the EDKII prefix, and the unaccepted memory type has the BZ3937 > > prefix. > > - Removed a bad #include to a header removed in v7. > > - Renamed the protocol to BZ3987_MEMORY_ACCEPTANCE_PROTOCOL > as per the > > discussion on the buganizer issue. > > - Uncrustify formatting > > > > Changes since v6: > > - Added implementation of > EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SERVICES. > > - Changed callback protocol of v5 to instead use the standardized event > > group for before_exit_boot_services. > > > > Changes since v5: > > - Generic callback protocol moved to MdeModulePkg > > - Removed use of EFI_WARN_STALE_DATA and added comment that the > callback > > should only return EFI_SUCCESS or EFI_INVALID_PARAMETER. > > - Removed errant log statement and fixed formatting. > > > > Changes since v4: > > - Commit message wording > > - Replaced direct change to DxeMain with a more generic callback > > protocol. > > - Implemented the direct change as an instance of the callback protocol > > from a new CocoDxe driver. > > - Replaced "enable" protocol with a "disable" protocol, since the name > > was confusing. The AcceptAllUnacceptedMemory protocol directly > names > > the behavior that is disabling. > > > > Changes since v3: > > - "DxeMain accepts all memory" patch split into 3 to make each patch > > affect only one package at a time. > > > > Changes since v2: > > - Removed the redundant memory accept interface and added the accept > > behavior to the DXE implementation of > > MemEncryptSevSnpPreValidateSystemRam. > > - Fixed missing #include in >=4GB patch. > > > > Changes since v1: > > - Added a patch to classify SEV-SNP memory above 4GB unaccepted. > > - Fixed style problems in EfiMemoryAcceptProtocol implementation. > > > > Cc: Ard Biescheuvel <ardb@kernel.org> > > Cc: "Min M. Xu" <min.m.xu@intel.com> > > Cc: Gerd Hoffmann <kraxel@redhat.com> > > Cc: James Bottomley <jejb@linux.ibm.com> > > Cc: Tom Lendacky <Thomas.Lendacky@amd.com> > > Cc: Jiewen Yao <jiewen.yao@intel.com> > > Cc: Erdem Aktas <erdemaktas@google.com> > > Cc: Andrew Fish <afish@apple.com> > > Cc: "Michael D. Kinney" <michael.d.kinney@intel.com> > > > > Signed-off-by: Dionna Glaze <dionnaglaze@google.com> > > > > Dionna Glaze (7): > > OvmfPkg: Realize EfiMemoryAcceptProtocol in AmdSevDxe > > MdePkg: Add EFI_EVENT_BEFORE_EXIT_BOOT_SERVICES_GUID > > MdeModulePkg: Notify BeforeExitBootServices in CoreExitBootServices > > OvmfPkg: Introduce CocoDxe driver > > MdePkg: Introduce the MemoryAcceptance protocol > > OvmfPkg: Implement AcceptAllUnacceptedMemory in CocoDxe > > OvmfPkg/PlatformPei: SEV-SNP make >=4GB unaccepted > > > > MdeModulePkg/Core/Dxe/DxeMain.inf | 1 + > > MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c | 6 + > > MdePkg/Include/Guid/EventGroup.h | 5 + > > MdePkg/Include/Protocol/MemoryAcceptance.h | 40 > +++++ > > MdePkg/MdePkg.dec | 8 +- > > OvmfPkg/AmdSev/AmdSevX64.dsc | 1 + > > OvmfPkg/AmdSev/AmdSevX64.fdf | 1 + > > OvmfPkg/AmdSevDxe/AmdSevDxe.c | 55 ++++++- > > OvmfPkg/AmdSevDxe/AmdSevDxe.inf | 3 + > > OvmfPkg/CocoDxe/CocoDxe.c | 174 > ++++++++++++++++++++ > > OvmfPkg/CocoDxe/CocoDxe.inf | 46 ++++++ > > OvmfPkg/IntelTdx/IntelTdxX64.dsc | 1 + > > OvmfPkg/IntelTdx/IntelTdxX64.fdf | 1 + > > > OvmfPkg/Library/BaseMemEncryptSevLib/X64/DxeSnpSystemRamValidate. > c | 24 ++- > > OvmfPkg/OvmfPkgIa32X64.dsc | 1 + > > OvmfPkg/OvmfPkgIa32X64.fdf | 1 + > > OvmfPkg/OvmfPkgX64.dsc | 1 + > > OvmfPkg/OvmfPkgX64.fdf | 1 + > > OvmfPkg/PlatformPei/AmdSev.c | 5 + > > 19 files changed, 366 insertions(+), 9 deletions(-) > > create mode 100644 MdePkg/Include/Protocol/MemoryAcceptance.h > > create mode 100644 OvmfPkg/CocoDxe/CocoDxe.c > > create mode 100644 OvmfPkg/CocoDxe/CocoDxe.inf > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#96083): https://edk2.groups.io/g/devel/message/96083 Mute This Topic: https://groups.io/mt/94544528/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On 11/8/22 10:09, Yao, Jiewen wrote: > Hi Tom/Dionna > I think this patch is addressing https://bugzilla.tianocore.org/show_bug.cgi?id=3987. > > For patch 1~3, I am OK for the API which we already agreed, such as EfiMemoryAcceptProtocol and EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SERVICES. > I have given Acked by: Jiewen Yao <Jiewen.yao@intel.com> > > For patch 4, it changed the behavior to accept all. I don’t believe it should be 4. It should be the latest one. (please correct me if I am wrong.) > > For patch 5~6, I cannot give R-B for BZ3987_MEMORY_ACCEPTANCE_PROTOCAL proposed here because it does not address my concern. Please refer to the discussion in the Bugzilla. > > > If you want to split the patch series and submit 1~3 as standalone one, that will match SEV to TDX on lazy accept part. I believe we may merge them after we get R-B from right person. Just FYI, without the last half of this series, I believe that TDX will only be accepting 4GB of memory when using OvmfPkgX64.dsc (see OvmfPkg/Library/PlatformInitLib/IntelTdx.c), while SNP will be accepting all memory. This would seem to present a problem for TDX with OvmfPkgX64.dsc if the OS does not have support for unaccepted memory. Thanks, Tom > > Thank you > Yao, Jiewen > > >> -----Original Message----- >> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of >> Lendacky, Thomas via groups.io >> Sent: Tuesday, November 8, 2022 10:38 PM >> To: Dionna Glaze <dionnaglaze@google.com>; devel@edk2.groups.io >> Cc: Ard Biescheuvel <ardb@kernel.org>; Xu, Min M <min.m.xu@intel.com>; >> Gerd Hoffmann <kraxel@redhat.com>; James Bottomley >> <jejb@linux.ibm.com>; Yao, Jiewen <jiewen.yao@intel.com>; Aktas, Erdem >> <erdemaktas@google.com>; Andrew Fish <afish@apple.com>; Kinney, >> Michael D <michael.d.kinney@intel.com> >> Subject: Re: [edk2-devel] [PATCH v8 0/7] Add safe unaccepted memory >> behavior >> >> On 10/24/22 15:41, Dionna Glaze wrote: >>> These seven patches build on the lazy-accept patch series >>> >>> "Introduce Lazy-accept for Tdx guest" >> >> Since the above series was accepted into the EDK2 tree, can this series >> also be pulled in so that both TDX and SNP can support unaccepted >> memory >> in the same release? >> >> Thanks, >> Tom >> >>> >>> by adding SEV-SNP support for the MemoryAccept protocol, and >>> importantly making eager memory acceptance the default behavior. >>> >>> We implement a standardized event group from UEFI v2.9, >>> EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SERVICES, since it provides >> exactly >>> the right invocation point for eagerly accepting memory if eager >>> acceptance has not been disabled. >>> >>> To make use of this event group, we add a new driver that is meant to >>> carry behavior that is needed for all confidential compute technologies, >>> not just specific platforms, CocoDxe. In CocoDxe we implement the >>> default safe behavior to accept all unaccepted memory and invalidate >>> the MemoryMap on ExitBootServices. >>> >>> To allow the OS loader to prevent the eager acceptance, we add a new >>> protocol, up for standardization, AcceptAllUnacceptedMemoryProtocol. >>> This protocol has one interface, Disable(). The OS loader can inform the >>> UEFI that it supports the unaccepted memory type and accepts the >>> responsibility to accept it. >>> >>> All images that support unaccepted memory must now locate and call >> this >>> new BZ3987_ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL and call >> the Disable >>> function. >>> >>> Changes since v7: >>> - Rebased onto lazy accept v4 patch series, so memory accept protocol >>> has the EDKII prefix, and the unaccepted memory type has the BZ3937 >>> prefix. >>> - Removed a bad #include to a header removed in v7. >>> - Renamed the protocol to BZ3987_MEMORY_ACCEPTANCE_PROTOCOL >> as per the >>> discussion on the buganizer issue. >>> - Uncrustify formatting >>> >>> Changes since v6: >>> - Added implementation of >> EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SERVICES. >>> - Changed callback protocol of v5 to instead use the standardized event >>> group for before_exit_boot_services. >>> >>> Changes since v5: >>> - Generic callback protocol moved to MdeModulePkg >>> - Removed use of EFI_WARN_STALE_DATA and added comment that the >> callback >>> should only return EFI_SUCCESS or EFI_INVALID_PARAMETER. >>> - Removed errant log statement and fixed formatting. >>> >>> Changes since v4: >>> - Commit message wording >>> - Replaced direct change to DxeMain with a more generic callback >>> protocol. >>> - Implemented the direct change as an instance of the callback protocol >>> from a new CocoDxe driver. >>> - Replaced "enable" protocol with a "disable" protocol, since the name >>> was confusing. The AcceptAllUnacceptedMemory protocol directly >> names >>> the behavior that is disabling. >>> >>> Changes since v3: >>> - "DxeMain accepts all memory" patch split into 3 to make each patch >>> affect only one package at a time. >>> >>> Changes since v2: >>> - Removed the redundant memory accept interface and added the accept >>> behavior to the DXE implementation of >>> MemEncryptSevSnpPreValidateSystemRam. >>> - Fixed missing #include in >=4GB patch. >>> >>> Changes since v1: >>> - Added a patch to classify SEV-SNP memory above 4GB unaccepted. >>> - Fixed style problems in EfiMemoryAcceptProtocol implementation. >>> >>> Cc: Ard Biescheuvel <ardb@kernel.org> >>> Cc: "Min M. Xu" <min.m.xu@intel.com> >>> Cc: Gerd Hoffmann <kraxel@redhat.com> >>> Cc: James Bottomley <jejb@linux.ibm.com> >>> Cc: Tom Lendacky <Thomas.Lendacky@amd.com> >>> Cc: Jiewen Yao <jiewen.yao@intel.com> >>> Cc: Erdem Aktas <erdemaktas@google.com> >>> Cc: Andrew Fish <afish@apple.com> >>> Cc: "Michael D. Kinney" <michael.d.kinney@intel.com> >>> >>> Signed-off-by: Dionna Glaze <dionnaglaze@google.com> >>> >>> Dionna Glaze (7): >>> OvmfPkg: Realize EfiMemoryAcceptProtocol in AmdSevDxe >>> MdePkg: Add EFI_EVENT_BEFORE_EXIT_BOOT_SERVICES_GUID >>> MdeModulePkg: Notify BeforeExitBootServices in CoreExitBootServices >>> OvmfPkg: Introduce CocoDxe driver >>> MdePkg: Introduce the MemoryAcceptance protocol >>> OvmfPkg: Implement AcceptAllUnacceptedMemory in CocoDxe >>> OvmfPkg/PlatformPei: SEV-SNP make >=4GB unaccepted >>> >>> MdeModulePkg/Core/Dxe/DxeMain.inf | 1 + >>> MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c | 6 + >>> MdePkg/Include/Guid/EventGroup.h | 5 + >>> MdePkg/Include/Protocol/MemoryAcceptance.h | 40 >> +++++ >>> MdePkg/MdePkg.dec | 8 +- >>> OvmfPkg/AmdSev/AmdSevX64.dsc | 1 + >>> OvmfPkg/AmdSev/AmdSevX64.fdf | 1 + >>> OvmfPkg/AmdSevDxe/AmdSevDxe.c | 55 ++++++- >>> OvmfPkg/AmdSevDxe/AmdSevDxe.inf | 3 + >>> OvmfPkg/CocoDxe/CocoDxe.c | 174 >> ++++++++++++++++++++ >>> OvmfPkg/CocoDxe/CocoDxe.inf | 46 ++++++ >>> OvmfPkg/IntelTdx/IntelTdxX64.dsc | 1 + >>> OvmfPkg/IntelTdx/IntelTdxX64.fdf | 1 + >>> >> OvmfPkg/Library/BaseMemEncryptSevLib/X64/DxeSnpSystemRamValidate. >> c | 24 ++- >>> OvmfPkg/OvmfPkgIa32X64.dsc | 1 + >>> OvmfPkg/OvmfPkgIa32X64.fdf | 1 + >>> OvmfPkg/OvmfPkgX64.dsc | 1 + >>> OvmfPkg/OvmfPkgX64.fdf | 1 + >>> OvmfPkg/PlatformPei/AmdSev.c | 5 + >>> 19 files changed, 366 insertions(+), 9 deletions(-) >>> create mode 100644 MdePkg/Include/Protocol/MemoryAcceptance.h >>> create mode 100644 OvmfPkg/CocoDxe/CocoDxe.c >>> create mode 100644 OvmfPkg/CocoDxe/CocoDxe.inf >>> >> >> >> >> > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#96109): https://edk2.groups.io/g/devel/message/96109 Mute This Topic: https://groups.io/mt/94544528/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On Tue, Nov 8, 2022 at 8:09 AM Yao, Jiewen <jiewen.yao@intel.com> wrote: > > Hi Tom/Dionna > I think this patch is addressing https://bugzilla.tianocore.org/show_bug.cgi?id=3987. > > For patch 1~3, I am OK for the API which we already agreed, such as EfiMemoryAcceptProtocol and EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SERVICES. > I have given Acked by: Jiewen Yao <Jiewen.yao@intel.com> > > For patch 4, it changed the behavior to accept all. I don’t believe it should be 4. It should be the latest one. (please correct me if I am wrong.) > The acceptance protocol (5-6) and the accept-all behavior (4) could be swapped in order, but they really only make sense as a pair. No client would use a new protocol to disable the behavior of something that doesn't happen. The accept-all behavior (4) must be default before SEV-SNP introduces unaccepted memory (7). > For patch 5~6, I cannot give R-B for BZ3987_MEMORY_ACCEPTANCE_PROTOCAL proposed here because it does not address my concern. Please refer to the discussion in the Bugzilla. > I don't think your concern is addressable given the constraints of a smooth upgrade path. I think the right folks to discuss this with you from the Intel side are Min Xu and Kirill Shutemov. Kirill will know what is feasible for the OS to inform the UEFI of in terms of memory required, and how to not break OSes that don't use the new protocol, whereas Min should know where that kind of information should be communicated. > > If you want to split the patch series and submit 1~3 as standalone one, that will match SEV to TDX on lazy accept part. I believe we may merge them after we get R-B from right person. > I can do that. > Thank you > Yao, Jiewen > > > > -----Original Message----- > > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of > > Lendacky, Thomas via groups.io > > Sent: Tuesday, November 8, 2022 10:38 PM > > To: Dionna Glaze <dionnaglaze@google.com>; devel@edk2.groups.io > > Cc: Ard Biescheuvel <ardb@kernel.org>; Xu, Min M <min.m.xu@intel.com>; > > Gerd Hoffmann <kraxel@redhat.com>; James Bottomley > > <jejb@linux.ibm.com>; Yao, Jiewen <jiewen.yao@intel.com>; Aktas, Erdem > > <erdemaktas@google.com>; Andrew Fish <afish@apple.com>; Kinney, > > Michael D <michael.d.kinney@intel.com> > > Subject: Re: [edk2-devel] [PATCH v8 0/7] Add safe unaccepted memory > > behavior > > > > On 10/24/22 15:41, Dionna Glaze wrote: > > > These seven patches build on the lazy-accept patch series > > > > > > "Introduce Lazy-accept for Tdx guest" > > > > Since the above series was accepted into the EDK2 tree, can this series > > also be pulled in so that both TDX and SNP can support unaccepted > > memory > > in the same release? > > > > Thanks, > > Tom > > > > > > > > by adding SEV-SNP support for the MemoryAccept protocol, and > > > importantly making eager memory acceptance the default behavior. > > > > > > We implement a standardized event group from UEFI v2.9, > > > EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SERVICES, since it provides > > exactly > > > the right invocation point for eagerly accepting memory if eager > > > acceptance has not been disabled. > > > > > > To make use of this event group, we add a new driver that is meant to > > > carry behavior that is needed for all confidential compute technologies, > > > not just specific platforms, CocoDxe. In CocoDxe we implement the > > > default safe behavior to accept all unaccepted memory and invalidate > > > the MemoryMap on ExitBootServices. > > > > > > To allow the OS loader to prevent the eager acceptance, we add a new > > > protocol, up for standardization, AcceptAllUnacceptedMemoryProtocol. > > > This protocol has one interface, Disable(). The OS loader can inform the > > > UEFI that it supports the unaccepted memory type and accepts the > > > responsibility to accept it. > > > > > > All images that support unaccepted memory must now locate and call > > this > > > new BZ3987_ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL and call > > the Disable > > > function. > > > > > > Changes since v7: > > > - Rebased onto lazy accept v4 patch series, so memory accept protocol > > > has the EDKII prefix, and the unaccepted memory type has the BZ3937 > > > prefix. > > > - Removed a bad #include to a header removed in v7. > > > - Renamed the protocol to BZ3987_MEMORY_ACCEPTANCE_PROTOCOL > > as per the > > > discussion on the buganizer issue. > > > - Uncrustify formatting > > > > > > Changes since v6: > > > - Added implementation of > > EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SERVICES. > > > - Changed callback protocol of v5 to instead use the standardized event > > > group for before_exit_boot_services. > > > > > > Changes since v5: > > > - Generic callback protocol moved to MdeModulePkg > > > - Removed use of EFI_WARN_STALE_DATA and added comment that the > > callback > > > should only return EFI_SUCCESS or EFI_INVALID_PARAMETER. > > > - Removed errant log statement and fixed formatting. > > > > > > Changes since v4: > > > - Commit message wording > > > - Replaced direct change to DxeMain with a more generic callback > > > protocol. > > > - Implemented the direct change as an instance of the callback protocol > > > from a new CocoDxe driver. > > > - Replaced "enable" protocol with a "disable" protocol, since the name > > > was confusing. The AcceptAllUnacceptedMemory protocol directly > > names > > > the behavior that is disabling. > > > > > > Changes since v3: > > > - "DxeMain accepts all memory" patch split into 3 to make each patch > > > affect only one package at a time. > > > > > > Changes since v2: > > > - Removed the redundant memory accept interface and added the accept > > > behavior to the DXE implementation of > > > MemEncryptSevSnpPreValidateSystemRam. > > > - Fixed missing #include in >=4GB patch. > > > > > > Changes since v1: > > > - Added a patch to classify SEV-SNP memory above 4GB unaccepted. > > > - Fixed style problems in EfiMemoryAcceptProtocol implementation. > > > > > > Cc: Ard Biescheuvel <ardb@kernel.org> > > > Cc: "Min M. Xu" <min.m.xu@intel.com> > > > Cc: Gerd Hoffmann <kraxel@redhat.com> > > > Cc: James Bottomley <jejb@linux.ibm.com> > > > Cc: Tom Lendacky <Thomas.Lendacky@amd.com> > > > Cc: Jiewen Yao <jiewen.yao@intel.com> > > > Cc: Erdem Aktas <erdemaktas@google.com> > > > Cc: Andrew Fish <afish@apple.com> > > > Cc: "Michael D. Kinney" <michael.d.kinney@intel.com> > > > > > > Signed-off-by: Dionna Glaze <dionnaglaze@google.com> > > > > > > Dionna Glaze (7): > > > OvmfPkg: Realize EfiMemoryAcceptProtocol in AmdSevDxe > > > MdePkg: Add EFI_EVENT_BEFORE_EXIT_BOOT_SERVICES_GUID > > > MdeModulePkg: Notify BeforeExitBootServices in CoreExitBootServices > > > OvmfPkg: Introduce CocoDxe driver > > > MdePkg: Introduce the MemoryAcceptance protocol > > > OvmfPkg: Implement AcceptAllUnacceptedMemory in CocoDxe > > > OvmfPkg/PlatformPei: SEV-SNP make >=4GB unaccepted > > > > > > MdeModulePkg/Core/Dxe/DxeMain.inf | 1 + > > > MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c | 6 + > > > MdePkg/Include/Guid/EventGroup.h | 5 + > > > MdePkg/Include/Protocol/MemoryAcceptance.h | 40 > > +++++ > > > MdePkg/MdePkg.dec | 8 +- > > > OvmfPkg/AmdSev/AmdSevX64.dsc | 1 + > > > OvmfPkg/AmdSev/AmdSevX64.fdf | 1 + > > > OvmfPkg/AmdSevDxe/AmdSevDxe.c | 55 ++++++- > > > OvmfPkg/AmdSevDxe/AmdSevDxe.inf | 3 + > > > OvmfPkg/CocoDxe/CocoDxe.c | 174 > > ++++++++++++++++++++ > > > OvmfPkg/CocoDxe/CocoDxe.inf | 46 ++++++ > > > OvmfPkg/IntelTdx/IntelTdxX64.dsc | 1 + > > > OvmfPkg/IntelTdx/IntelTdxX64.fdf | 1 + > > > > > OvmfPkg/Library/BaseMemEncryptSevLib/X64/DxeSnpSystemRamValidate. > > c | 24 ++- > > > OvmfPkg/OvmfPkgIa32X64.dsc | 1 + > > > OvmfPkg/OvmfPkgIa32X64.fdf | 1 + > > > OvmfPkg/OvmfPkgX64.dsc | 1 + > > > OvmfPkg/OvmfPkgX64.fdf | 1 + > > > OvmfPkg/PlatformPei/AmdSev.c | 5 + > > > 19 files changed, 366 insertions(+), 9 deletions(-) > > > create mode 100644 MdePkg/Include/Protocol/MemoryAcceptance.h > > > create mode 100644 OvmfPkg/CocoDxe/CocoDxe.c > > > create mode 100644 OvmfPkg/CocoDxe/CocoDxe.inf > > > > > > > > > > > > -- -Dionna Glaze, PhD (she/her) -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#96084): https://edk2.groups.io/g/devel/message/96084 Mute This Topic: https://groups.io/mt/94544528/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
Right, Dionna. In intel, we are doing POC to see what is the best size the BIOS should accept. The total time for memory accept is 4 part: 1) vBIOS early phase, single thread accept 2) vBIOS runtime phase, multi thread accept 3) OS early phase, single thread accept 4) OS runtime phase, multi thread accept We hope 1) is zero. And we are trying to balance between 2) and 3). I hope to discuss more after we get the data. Then we can discuss how to achieve best performance. BTW: Is there any data for AMD-SEV? Thank you Yao, Jiewen > -----Original Message----- > From: Dionna Amalie Glaze <dionnaglaze@google.com> > Sent: Wednesday, November 9, 2022 12:23 AM > To: Yao, Jiewen <jiewen.yao@intel.com> > Cc: devel@edk2.groups.io; thomas.lendacky@amd.com; Ard Biescheuvel > <ardb@kernel.org>; Xu, Min M <min.m.xu@intel.com>; Gerd Hoffmann > <kraxel@redhat.com>; James Bottomley <jejb@linux.ibm.com>; Aktas, > Erdem <erdemaktas@google.com>; Andrew Fish <afish@apple.com>; > Kinney, Michael D <michael.d.kinney@intel.com> > Subject: Re: [edk2-devel] [PATCH v8 0/7] Add safe unaccepted memory > behavior > > On Tue, Nov 8, 2022 at 8:09 AM Yao, Jiewen <jiewen.yao@intel.com> wrote: > > > > Hi Tom/Dionna > > I think this patch is addressing > https://bugzilla.tianocore.org/show_bug.cgi?id=3987. > > > > For patch 1~3, I am OK for the API which we already agreed, such as > EfiMemoryAcceptProtocol and > EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SERVICES. > > I have given Acked by: Jiewen Yao <Jiewen.yao@intel.com> > > > > For patch 4, it changed the behavior to accept all. I don’t believe it should > be 4. It should be the latest one. (please correct me if I am wrong.) > > > > The acceptance protocol (5-6) and the accept-all behavior (4) could be > swapped in order, but they really only make sense as a pair. No client > would use a new protocol to disable the behavior of something that > doesn't happen. > The accept-all behavior (4) must be default before SEV-SNP introduces > unaccepted memory (7). > > > For patch 5~6, I cannot give R-B for > BZ3987_MEMORY_ACCEPTANCE_PROTOCAL proposed here because it does > not address my concern. Please refer to the discussion in the Bugzilla. > > > > I don't think your concern is addressable given the constraints of a > smooth upgrade path. I think the right folks to discuss this with you > from the Intel side are Min Xu and Kirill Shutemov. Kirill will know > what is feasible for the OS to inform the UEFI of in terms of memory > required, and how to not break OSes that don't use the new protocol, > whereas Min should know where that kind of information should be > communicated. > > > > > If you want to split the patch series and submit 1~3 as standalone one, > that will match SEV to TDX on lazy accept part. I believe we may merge > them after we get R-B from right person. > > > > I can do that. > > > Thank you > > Yao, Jiewen > > > > > > > -----Original Message----- > > > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of > > > Lendacky, Thomas via groups.io > > > Sent: Tuesday, November 8, 2022 10:38 PM > > > To: Dionna Glaze <dionnaglaze@google.com>; devel@edk2.groups.io > > > Cc: Ard Biescheuvel <ardb@kernel.org>; Xu, Min M > <min.m.xu@intel.com>; > > > Gerd Hoffmann <kraxel@redhat.com>; James Bottomley > > > <jejb@linux.ibm.com>; Yao, Jiewen <jiewen.yao@intel.com>; Aktas, > Erdem > > > <erdemaktas@google.com>; Andrew Fish <afish@apple.com>; Kinney, > > > Michael D <michael.d.kinney@intel.com> > > > Subject: Re: [edk2-devel] [PATCH v8 0/7] Add safe unaccepted memory > > > behavior > > > > > > On 10/24/22 15:41, Dionna Glaze wrote: > > > > These seven patches build on the lazy-accept patch series > > > > > > > > "Introduce Lazy-accept for Tdx guest" > > > > > > Since the above series was accepted into the EDK2 tree, can this series > > > also be pulled in so that both TDX and SNP can support unaccepted > > > memory > > > in the same release? > > > > > > Thanks, > > > Tom > > > > > > > > > > > by adding SEV-SNP support for the MemoryAccept protocol, and > > > > importantly making eager memory acceptance the default behavior. > > > > > > > > We implement a standardized event group from UEFI v2.9, > > > > EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SERVICES, since it provides > > > exactly > > > > the right invocation point for eagerly accepting memory if eager > > > > acceptance has not been disabled. > > > > > > > > To make use of this event group, we add a new driver that is meant to > > > > carry behavior that is needed for all confidential compute > technologies, > > > > not just specific platforms, CocoDxe. In CocoDxe we implement the > > > > default safe behavior to accept all unaccepted memory and invalidate > > > > the MemoryMap on ExitBootServices. > > > > > > > > To allow the OS loader to prevent the eager acceptance, we add a new > > > > protocol, up for standardization, > AcceptAllUnacceptedMemoryProtocol. > > > > This protocol has one interface, Disable(). The OS loader can inform > the > > > > UEFI that it supports the unaccepted memory type and accepts the > > > > responsibility to accept it. > > > > > > > > All images that support unaccepted memory must now locate and call > > > this > > > > new BZ3987_ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL and > call > > > the Disable > > > > function. > > > > > > > > Changes since v7: > > > > - Rebased onto lazy accept v4 patch series, so memory accept > protocol > > > > has the EDKII prefix, and the unaccepted memory type has the > BZ3937 > > > > prefix. > > > > - Removed a bad #include to a header removed in v7. > > > > - Renamed the protocol to > BZ3987_MEMORY_ACCEPTANCE_PROTOCOL > > > as per the > > > > discussion on the buganizer issue. > > > > - Uncrustify formatting > > > > > > > > Changes since v6: > > > > - Added implementation of > > > EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SERVICES. > > > > - Changed callback protocol of v5 to instead use the standardized > event > > > > group for before_exit_boot_services. > > > > > > > > Changes since v5: > > > > - Generic callback protocol moved to MdeModulePkg > > > > - Removed use of EFI_WARN_STALE_DATA and added comment that > the > > > callback > > > > should only return EFI_SUCCESS or EFI_INVALID_PARAMETER. > > > > - Removed errant log statement and fixed formatting. > > > > > > > > Changes since v4: > > > > - Commit message wording > > > > - Replaced direct change to DxeMain with a more generic callback > > > > protocol. > > > > - Implemented the direct change as an instance of the callback > protocol > > > > from a new CocoDxe driver. > > > > - Replaced "enable" protocol with a "disable" protocol, since the > name > > > > was confusing. The AcceptAllUnacceptedMemory protocol directly > > > names > > > > the behavior that is disabling. > > > > > > > > Changes since v3: > > > > - "DxeMain accepts all memory" patch split into 3 to make each > patch > > > > affect only one package at a time. > > > > > > > > Changes since v2: > > > > - Removed the redundant memory accept interface and added the > accept > > > > behavior to the DXE implementation of > > > > MemEncryptSevSnpPreValidateSystemRam. > > > > - Fixed missing #include in >=4GB patch. > > > > > > > > Changes since v1: > > > > - Added a patch to classify SEV-SNP memory above 4GB unaccepted. > > > > - Fixed style problems in EfiMemoryAcceptProtocol implementation. > > > > > > > > Cc: Ard Biescheuvel <ardb@kernel.org> > > > > Cc: "Min M. Xu" <min.m.xu@intel.com> > > > > Cc: Gerd Hoffmann <kraxel@redhat.com> > > > > Cc: James Bottomley <jejb@linux.ibm.com> > > > > Cc: Tom Lendacky <Thomas.Lendacky@amd.com> > > > > Cc: Jiewen Yao <jiewen.yao@intel.com> > > > > Cc: Erdem Aktas <erdemaktas@google.com> > > > > Cc: Andrew Fish <afish@apple.com> > > > > Cc: "Michael D. Kinney" <michael.d.kinney@intel.com> > > > > > > > > Signed-off-by: Dionna Glaze <dionnaglaze@google.com> > > > > > > > > Dionna Glaze (7): > > > > OvmfPkg: Realize EfiMemoryAcceptProtocol in AmdSevDxe > > > > MdePkg: Add EFI_EVENT_BEFORE_EXIT_BOOT_SERVICES_GUID > > > > MdeModulePkg: Notify BeforeExitBootServices in > CoreExitBootServices > > > > OvmfPkg: Introduce CocoDxe driver > > > > MdePkg: Introduce the MemoryAcceptance protocol > > > > OvmfPkg: Implement AcceptAllUnacceptedMemory in CocoDxe > > > > OvmfPkg/PlatformPei: SEV-SNP make >=4GB unaccepted > > > > > > > > MdeModulePkg/Core/Dxe/DxeMain.inf | 1 + > > > > MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c | 6 > + > > > > MdePkg/Include/Guid/EventGroup.h | 5 + > > > > MdePkg/Include/Protocol/MemoryAcceptance.h | 40 > > > +++++ > > > > MdePkg/MdePkg.dec | 8 +- > > > > OvmfPkg/AmdSev/AmdSevX64.dsc | 1 + > > > > OvmfPkg/AmdSev/AmdSevX64.fdf | 1 + > > > > OvmfPkg/AmdSevDxe/AmdSevDxe.c | 55 > ++++++- > > > > OvmfPkg/AmdSevDxe/AmdSevDxe.inf | 3 + > > > > OvmfPkg/CocoDxe/CocoDxe.c | 174 > > > ++++++++++++++++++++ > > > > OvmfPkg/CocoDxe/CocoDxe.inf | 46 ++++++ > > > > OvmfPkg/IntelTdx/IntelTdxX64.dsc | 1 + > > > > OvmfPkg/IntelTdx/IntelTdxX64.fdf | 1 + > > > > > > > > OvmfPkg/Library/BaseMemEncryptSevLib/X64/DxeSnpSystemRamValidate. > > > c | 24 ++- > > > > OvmfPkg/OvmfPkgIa32X64.dsc | 1 + > > > > OvmfPkg/OvmfPkgIa32X64.fdf | 1 + > > > > OvmfPkg/OvmfPkgX64.dsc | 1 + > > > > OvmfPkg/OvmfPkgX64.fdf | 1 + > > > > OvmfPkg/PlatformPei/AmdSev.c | 5 + > > > > 19 files changed, 366 insertions(+), 9 deletions(-) > > > > create mode 100644 > MdePkg/Include/Protocol/MemoryAcceptance.h > > > > create mode 100644 OvmfPkg/CocoDxe/CocoDxe.c > > > > create mode 100644 OvmfPkg/CocoDxe/CocoDxe.inf > > > > > > > > > > > > > > > > > > > > > -- > -Dionna Glaze, PhD (she/her) -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#96086): https://edk2.groups.io/g/devel/message/96086 Mute This Topic: https://groups.io/mt/94544528/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
> > BTW: Is there any data for AMD-SEV? > Earlier this year, I tried to make the lazy accept patches work for SEV-SNP, but the boot would always crash in the Qemu try boot kernel step IIRC: https://github.com/AMDESE/ovmf/pull/4 Tom suggested accepting the first 4GiB and I didn't go back to try to make the more complicated solution work, since accepting the HOB up to the MMIO hole took roughly 30ms, which is well within our boot budget given the outsized cost of pinning memory. The launch sequence (start, update_data*, finish) for OVMF takes about 190ms, which we can't make any lower. > > Thank you > Yao, Jiewen > > > > -----Original Message----- > > From: Dionna Amalie Glaze <dionnaglaze@google.com> > > Sent: Wednesday, November 9, 2022 12:23 AM > > To: Yao, Jiewen <jiewen.yao@intel.com> > > Cc: devel@edk2.groups.io; thomas.lendacky@amd.com; Ard Biescheuvel > > <ardb@kernel.org>; Xu, Min M <min.m.xu@intel.com>; Gerd Hoffmann > > <kraxel@redhat.com>; James Bottomley <jejb@linux.ibm.com>; Aktas, > > Erdem <erdemaktas@google.com>; Andrew Fish <afish@apple.com>; > > Kinney, Michael D <michael.d.kinney@intel.com> > > Subject: Re: [edk2-devel] [PATCH v8 0/7] Add safe unaccepted memory > > behavior > > > > On Tue, Nov 8, 2022 at 8:09 AM Yao, Jiewen <jiewen.yao@intel.com> wrote: > > > > > > Hi Tom/Dionna > > > I think this patch is addressing > > https://bugzilla.tianocore.org/show_bug.cgi?id=3987. > > > > > > For patch 1~3, I am OK for the API which we already agreed, such as > > EfiMemoryAcceptProtocol and > > EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SERVICES. > > > I have given Acked by: Jiewen Yao <Jiewen.yao@intel.com> > > > > > > For patch 4, it changed the behavior to accept all. I don’t believe it should > > be 4. It should be the latest one. (please correct me if I am wrong.) > > > > > > > The acceptance protocol (5-6) and the accept-all behavior (4) could be > > swapped in order, but they really only make sense as a pair. No client > > would use a new protocol to disable the behavior of something that > > doesn't happen. > > The accept-all behavior (4) must be default before SEV-SNP introduces > > unaccepted memory (7). > > > > > For patch 5~6, I cannot give R-B for > > BZ3987_MEMORY_ACCEPTANCE_PROTOCAL proposed here because it does > > not address my concern. Please refer to the discussion in the Bugzilla. > > > > > > > I don't think your concern is addressable given the constraints of a > > smooth upgrade path. I think the right folks to discuss this with you > > from the Intel side are Min Xu and Kirill Shutemov. Kirill will know > > what is feasible for the OS to inform the UEFI of in terms of memory > > required, and how to not break OSes that don't use the new protocol, > > whereas Min should know where that kind of information should be > > communicated. > > > > > > > > If you want to split the patch series and submit 1~3 as standalone one, > > that will match SEV to TDX on lazy accept part. I believe we may merge > > them after we get R-B from right person. > > > > > > > I can do that. > > > > > Thank you > > > Yao, Jiewen > > > > > > > > > > -----Original Message----- > > > > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of > > > > Lendacky, Thomas via groups.io > > > > Sent: Tuesday, November 8, 2022 10:38 PM > > > > To: Dionna Glaze <dionnaglaze@google.com>; devel@edk2.groups.io > > > > Cc: Ard Biescheuvel <ardb@kernel.org>; Xu, Min M > > <min.m.xu@intel.com>; > > > > Gerd Hoffmann <kraxel@redhat.com>; James Bottomley > > > > <jejb@linux.ibm.com>; Yao, Jiewen <jiewen.yao@intel.com>; Aktas, > > Erdem > > > > <erdemaktas@google.com>; Andrew Fish <afish@apple.com>; Kinney, > > > > Michael D <michael.d.kinney@intel.com> > > > > Subject: Re: [edk2-devel] [PATCH v8 0/7] Add safe unaccepted memory > > > > behavior > > > > > > > > On 10/24/22 15:41, Dionna Glaze wrote: > > > > > These seven patches build on the lazy-accept patch series > > > > > > > > > > "Introduce Lazy-accept for Tdx guest" > > > > > > > > Since the above series was accepted into the EDK2 tree, can this series > > > > also be pulled in so that both TDX and SNP can support unaccepted > > > > memory > > > > in the same release? > > > > > > > > Thanks, > > > > Tom > > > > > > > > > > > > > > by adding SEV-SNP support for the MemoryAccept protocol, and > > > > > importantly making eager memory acceptance the default behavior. > > > > > > > > > > We implement a standardized event group from UEFI v2.9, > > > > > EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SERVICES, since it provides > > > > exactly > > > > > the right invocation point for eagerly accepting memory if eager > > > > > acceptance has not been disabled. > > > > > > > > > > To make use of this event group, we add a new driver that is meant to > > > > > carry behavior that is needed for all confidential compute > > technologies, > > > > > not just specific platforms, CocoDxe. In CocoDxe we implement the > > > > > default safe behavior to accept all unaccepted memory and invalidate > > > > > the MemoryMap on ExitBootServices. > > > > > > > > > > To allow the OS loader to prevent the eager acceptance, we add a new > > > > > protocol, up for standardization, > > AcceptAllUnacceptedMemoryProtocol. > > > > > This protocol has one interface, Disable(). The OS loader can inform > > the > > > > > UEFI that it supports the unaccepted memory type and accepts the > > > > > responsibility to accept it. > > > > > > > > > > All images that support unaccepted memory must now locate and call > > > > this > > > > > new BZ3987_ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL and > > call > > > > the Disable > > > > > function. > > > > > > > > > > Changes since v7: > > > > > - Rebased onto lazy accept v4 patch series, so memory accept > > protocol > > > > > has the EDKII prefix, and the unaccepted memory type has the > > BZ3937 > > > > > prefix. > > > > > - Removed a bad #include to a header removed in v7. > > > > > - Renamed the protocol to > > BZ3987_MEMORY_ACCEPTANCE_PROTOCOL > > > > as per the > > > > > discussion on the buganizer issue. > > > > > - Uncrustify formatting > > > > > > > > > > Changes since v6: > > > > > - Added implementation of > > > > EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SERVICES. > > > > > - Changed callback protocol of v5 to instead use the standardized > > event > > > > > group for before_exit_boot_services. > > > > > > > > > > Changes since v5: > > > > > - Generic callback protocol moved to MdeModulePkg > > > > > - Removed use of EFI_WARN_STALE_DATA and added comment that > > the > > > > callback > > > > > should only return EFI_SUCCESS or EFI_INVALID_PARAMETER. > > > > > - Removed errant log statement and fixed formatting. > > > > > > > > > > Changes since v4: > > > > > - Commit message wording > > > > > - Replaced direct change to DxeMain with a more generic callback > > > > > protocol. > > > > > - Implemented the direct change as an instance of the callback > > protocol > > > > > from a new CocoDxe driver. > > > > > - Replaced "enable" protocol with a "disable" protocol, since the > > name > > > > > was confusing. The AcceptAllUnacceptedMemory protocol directly > > > > names > > > > > the behavior that is disabling. > > > > > > > > > > Changes since v3: > > > > > - "DxeMain accepts all memory" patch split into 3 to make each > > patch > > > > > affect only one package at a time. > > > > > > > > > > Changes since v2: > > > > > - Removed the redundant memory accept interface and added the > > accept > > > > > behavior to the DXE implementation of > > > > > MemEncryptSevSnpPreValidateSystemRam. > > > > > - Fixed missing #include in >=4GB patch. > > > > > > > > > > Changes since v1: > > > > > - Added a patch to classify SEV-SNP memory above 4GB unaccepted. > > > > > - Fixed style problems in EfiMemoryAcceptProtocol implementation. > > > > > > > > > > Cc: Ard Biescheuvel <ardb@kernel.org> > > > > > Cc: "Min M. Xu" <min.m.xu@intel.com> > > > > > Cc: Gerd Hoffmann <kraxel@redhat.com> > > > > > Cc: James Bottomley <jejb@linux.ibm.com> > > > > > Cc: Tom Lendacky <Thomas.Lendacky@amd.com> > > > > > Cc: Jiewen Yao <jiewen.yao@intel.com> > > > > > Cc: Erdem Aktas <erdemaktas@google.com> > > > > > Cc: Andrew Fish <afish@apple.com> > > > > > Cc: "Michael D. Kinney" <michael.d.kinney@intel.com> > > > > > > > > > > Signed-off-by: Dionna Glaze <dionnaglaze@google.com> > > > > > > > > > > Dionna Glaze (7): > > > > > OvmfPkg: Realize EfiMemoryAcceptProtocol in AmdSevDxe > > > > > MdePkg: Add EFI_EVENT_BEFORE_EXIT_BOOT_SERVICES_GUID > > > > > MdeModulePkg: Notify BeforeExitBootServices in > > CoreExitBootServices > > > > > OvmfPkg: Introduce CocoDxe driver > > > > > MdePkg: Introduce the MemoryAcceptance protocol > > > > > OvmfPkg: Implement AcceptAllUnacceptedMemory in CocoDxe > > > > > OvmfPkg/PlatformPei: SEV-SNP make >=4GB unaccepted > > > > > > > > > > MdeModulePkg/Core/Dxe/DxeMain.inf | 1 + > > > > > MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c | 6 > > + > > > > > MdePkg/Include/Guid/EventGroup.h | 5 + > > > > > MdePkg/Include/Protocol/MemoryAcceptance.h | 40 > > > > +++++ > > > > > MdePkg/MdePkg.dec | 8 +- > > > > > OvmfPkg/AmdSev/AmdSevX64.dsc | 1 + > > > > > OvmfPkg/AmdSev/AmdSevX64.fdf | 1 + > > > > > OvmfPkg/AmdSevDxe/AmdSevDxe.c | 55 > > ++++++- > > > > > OvmfPkg/AmdSevDxe/AmdSevDxe.inf | 3 + > > > > > OvmfPkg/CocoDxe/CocoDxe.c | 174 > > > > ++++++++++++++++++++ > > > > > OvmfPkg/CocoDxe/CocoDxe.inf | 46 ++++++ > > > > > OvmfPkg/IntelTdx/IntelTdxX64.dsc | 1 + > > > > > OvmfPkg/IntelTdx/IntelTdxX64.fdf | 1 + > > > > > > > > > > > OvmfPkg/Library/BaseMemEncryptSevLib/X64/DxeSnpSystemRamValidate. > > > > c | 24 ++- > > > > > OvmfPkg/OvmfPkgIa32X64.dsc | 1 + > > > > > OvmfPkg/OvmfPkgIa32X64.fdf | 1 + > > > > > OvmfPkg/OvmfPkgX64.dsc | 1 + > > > > > OvmfPkg/OvmfPkgX64.fdf | 1 + > > > > > OvmfPkg/PlatformPei/AmdSev.c | 5 + > > > > > 19 files changed, 366 insertions(+), 9 deletions(-) > > > > > create mode 100644 > > MdePkg/Include/Protocol/MemoryAcceptance.h > > > > > create mode 100644 OvmfPkg/CocoDxe/CocoDxe.c > > > > > create mode 100644 OvmfPkg/CocoDxe/CocoDxe.inf > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > -Dionna Glaze, PhD (she/her) -- -Dionna Glaze, PhD (she/her) -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#96087): https://edk2.groups.io/g/devel/message/96087 Mute This Topic: https://groups.io/mt/94544528/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
> The total time for memory accept is 4 part: >1) vBIOS early phase, single thread accept >2) vBIOS runtime phase, multi thread accept >3) OS early phase, single thread accept >4) OS runtime phase, multi thread accept > >We hope 1) is zero. >And we are trying to balance between 2) and 3). Do you have a sense of how once you have that balance determined you would specify accepting less than 4GB when an OS supports it, and accepting 4GB when an OS doesn't? I'm not familiar enough with vBIOS memory allocation to know how runtime stacks are created. If we're in the situation images are "self-contained" in that the only memory that must be accepted is just enough to fit the binary size of an image, and then the image uses AllocatePages to allocate its own stack and whatever else, then we could be okay to not require any pre-acceptance. The lazy accept Min proposed in Page.c seems like it'd be fine enough to handle all memory use prior to the accept decision at EBS. This doesn't appear to be the world in which we live, given the crashes I experienced in the above mentioned PR, but I could try again. If we're not in the "self-contained" image situation, I don't know what allocation decisions happen during the StartImage process. If an image expects memory to be accessible that isn't part of the image binary itself, other than the two tables passed into the entry point, I don't know what that would be. That implicit expectation would need to become explicit with a binary format change to all EFI modules, to state their requirements before starting. If an EFI module doesn't specify its requirements, we assume that the 4GB amount must be accepted. A bootloader would need to do something similar when parsing the OS binary header: what memory is needed? Accept that if specified, or accept the 4GB for safety. These are very tricky cross-community problems to solve, and I don't think it's appropriate to lump it in with a simple protocol that we know is safe and performs well enough. > > I hope to discuss more after we get the data. Do you think that'll happen before mid-December? Thanks, -Dionna On Tue, Nov 8, 2022 at 8:43 AM Dionna Amalie Glaze <dionnaglaze@google.com> wrote: > > > > > BTW: Is there any data for AMD-SEV? > > > > Earlier this year, I tried to make the lazy accept patches work for > SEV-SNP, but the boot would always crash in the Qemu try boot kernel > step IIRC: > > https://github.com/AMDESE/ovmf/pull/4 > > Tom suggested accepting the first 4GiB and I didn't go back to try to > make the more complicated solution work, since accepting the HOB up to > the MMIO hole took roughly 30ms, which is well within our boot budget > given the outsized cost of pinning memory. The launch sequence (start, > update_data*, finish) for OVMF takes about 190ms, which we can't make > any lower. > > > > > Thank you > > Yao, Jiewen > > > > > > > -----Original Message----- > > > From: Dionna Amalie Glaze <dionnaglaze@google.com> > > > Sent: Wednesday, November 9, 2022 12:23 AM > > > To: Yao, Jiewen <jiewen.yao@intel.com> > > > Cc: devel@edk2.groups.io; thomas.lendacky@amd.com; Ard Biescheuvel > > > <ardb@kernel.org>; Xu, Min M <min.m.xu@intel.com>; Gerd Hoffmann > > > <kraxel@redhat.com>; James Bottomley <jejb@linux.ibm.com>; Aktas, > > > Erdem <erdemaktas@google.com>; Andrew Fish <afish@apple.com>; > > > Kinney, Michael D <michael.d.kinney@intel.com> > > > Subject: Re: [edk2-devel] [PATCH v8 0/7] Add safe unaccepted memory > > > behavior > > > > > > On Tue, Nov 8, 2022 at 8:09 AM Yao, Jiewen <jiewen.yao@intel.com> wrote: > > > > > > > > Hi Tom/Dionna > > > > I think this patch is addressing > > > https://bugzilla.tianocore.org/show_bug.cgi?id=3987. > > > > > > > > For patch 1~3, I am OK for the API which we already agreed, such as > > > EfiMemoryAcceptProtocol and > > > EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SERVICES. > > > > I have given Acked by: Jiewen Yao <Jiewen.yao@intel.com> > > > > > > > > For patch 4, it changed the behavior to accept all. I don’t believe it should > > > be 4. It should be the latest one. (please correct me if I am wrong.) > > > > > > > > > > The acceptance protocol (5-6) and the accept-all behavior (4) could be > > > swapped in order, but they really only make sense as a pair. No client > > > would use a new protocol to disable the behavior of something that > > > doesn't happen. > > > The accept-all behavior (4) must be default before SEV-SNP introduces > > > unaccepted memory (7). > > > > > > > For patch 5~6, I cannot give R-B for > > > BZ3987_MEMORY_ACCEPTANCE_PROTOCAL proposed here because it does > > > not address my concern. Please refer to the discussion in the Bugzilla. > > > > > > > > > > I don't think your concern is addressable given the constraints of a > > > smooth upgrade path. I think the right folks to discuss this with you > > > from the Intel side are Min Xu and Kirill Shutemov. Kirill will know > > > what is feasible for the OS to inform the UEFI of in terms of memory > > > required, and how to not break OSes that don't use the new protocol, > > > whereas Min should know where that kind of information should be > > > communicated. > > > > > > > > > > > If you want to split the patch series and submit 1~3 as standalone one, > > > that will match SEV to TDX on lazy accept part. I believe we may merge > > > them after we get R-B from right person. > > > > > > > > > > I can do that. > > > > > > > Thank you > > > > Yao, Jiewen > > > > > > > > > > > > > -----Original Message----- > > > > > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of > > > > > Lendacky, Thomas via groups.io > > > > > Sent: Tuesday, November 8, 2022 10:38 PM > > > > > To: Dionna Glaze <dionnaglaze@google.com>; devel@edk2.groups.io > > > > > Cc: Ard Biescheuvel <ardb@kernel.org>; Xu, Min M > > > <min.m.xu@intel.com>; > > > > > Gerd Hoffmann <kraxel@redhat.com>; James Bottomley > > > > > <jejb@linux.ibm.com>; Yao, Jiewen <jiewen.yao@intel.com>; Aktas, > > > Erdem > > > > > <erdemaktas@google.com>; Andrew Fish <afish@apple.com>; Kinney, > > > > > Michael D <michael.d.kinney@intel.com> > > > > > Subject: Re: [edk2-devel] [PATCH v8 0/7] Add safe unaccepted memory > > > > > behavior > > > > > > > > > > On 10/24/22 15:41, Dionna Glaze wrote: > > > > > > These seven patches build on the lazy-accept patch series > > > > > > > > > > > > "Introduce Lazy-accept for Tdx guest" > > > > > > > > > > Since the above series was accepted into the EDK2 tree, can this series > > > > > also be pulled in so that both TDX and SNP can support unaccepted > > > > > memory > > > > > in the same release? > > > > > > > > > > Thanks, > > > > > Tom > > > > > > > > > > > > > > > > > by adding SEV-SNP support for the MemoryAccept protocol, and > > > > > > importantly making eager memory acceptance the default behavior. > > > > > > > > > > > > We implement a standardized event group from UEFI v2.9, > > > > > > EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SERVICES, since it provides > > > > > exactly > > > > > > the right invocation point for eagerly accepting memory if eager > > > > > > acceptance has not been disabled. > > > > > > > > > > > > To make use of this event group, we add a new driver that is meant to > > > > > > carry behavior that is needed for all confidential compute > > > technologies, > > > > > > not just specific platforms, CocoDxe. In CocoDxe we implement the > > > > > > default safe behavior to accept all unaccepted memory and invalidate > > > > > > the MemoryMap on ExitBootServices. > > > > > > > > > > > > To allow the OS loader to prevent the eager acceptance, we add a new > > > > > > protocol, up for standardization, > > > AcceptAllUnacceptedMemoryProtocol. > > > > > > This protocol has one interface, Disable(). The OS loader can inform > > > the > > > > > > UEFI that it supports the unaccepted memory type and accepts the > > > > > > responsibility to accept it. > > > > > > > > > > > > All images that support unaccepted memory must now locate and call > > > > > this > > > > > > new BZ3987_ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL and > > > call > > > > > the Disable > > > > > > function. > > > > > > > > > > > > Changes since v7: > > > > > > - Rebased onto lazy accept v4 patch series, so memory accept > > > protocol > > > > > > has the EDKII prefix, and the unaccepted memory type has the > > > BZ3937 > > > > > > prefix. > > > > > > - Removed a bad #include to a header removed in v7. > > > > > > - Renamed the protocol to > > > BZ3987_MEMORY_ACCEPTANCE_PROTOCOL > > > > > as per the > > > > > > discussion on the buganizer issue. > > > > > > - Uncrustify formatting > > > > > > > > > > > > Changes since v6: > > > > > > - Added implementation of > > > > > EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SERVICES. > > > > > > - Changed callback protocol of v5 to instead use the standardized > > > event > > > > > > group for before_exit_boot_services. > > > > > > > > > > > > Changes since v5: > > > > > > - Generic callback protocol moved to MdeModulePkg > > > > > > - Removed use of EFI_WARN_STALE_DATA and added comment that > > > the > > > > > callback > > > > > > should only return EFI_SUCCESS or EFI_INVALID_PARAMETER. > > > > > > - Removed errant log statement and fixed formatting. > > > > > > > > > > > > Changes since v4: > > > > > > - Commit message wording > > > > > > - Replaced direct change to DxeMain with a more generic callback > > > > > > protocol. > > > > > > - Implemented the direct change as an instance of the callback > > > protocol > > > > > > from a new CocoDxe driver. > > > > > > - Replaced "enable" protocol with a "disable" protocol, since the > > > name > > > > > > was confusing. The AcceptAllUnacceptedMemory protocol directly > > > > > names > > > > > > the behavior that is disabling. > > > > > > > > > > > > Changes since v3: > > > > > > - "DxeMain accepts all memory" patch split into 3 to make each > > > patch > > > > > > affect only one package at a time. > > > > > > > > > > > > Changes since v2: > > > > > > - Removed the redundant memory accept interface and added the > > > accept > > > > > > behavior to the DXE implementation of > > > > > > MemEncryptSevSnpPreValidateSystemRam. > > > > > > - Fixed missing #include in >=4GB patch. > > > > > > > > > > > > Changes since v1: > > > > > > - Added a patch to classify SEV-SNP memory above 4GB unaccepted. > > > > > > - Fixed style problems in EfiMemoryAcceptProtocol implementation. > > > > > > > > > > > > Cc: Ard Biescheuvel <ardb@kernel.org> > > > > > > Cc: "Min M. Xu" <min.m.xu@intel.com> > > > > > > Cc: Gerd Hoffmann <kraxel@redhat.com> > > > > > > Cc: James Bottomley <jejb@linux.ibm.com> > > > > > > Cc: Tom Lendacky <Thomas.Lendacky@amd.com> > > > > > > Cc: Jiewen Yao <jiewen.yao@intel.com> > > > > > > Cc: Erdem Aktas <erdemaktas@google.com> > > > > > > Cc: Andrew Fish <afish@apple.com> > > > > > > Cc: "Michael D. Kinney" <michael.d.kinney@intel.com> > > > > > > > > > > > > Signed-off-by: Dionna Glaze <dionnaglaze@google.com> > > > > > > > > > > > > Dionna Glaze (7): > > > > > > OvmfPkg: Realize EfiMemoryAcceptProtocol in AmdSevDxe > > > > > > MdePkg: Add EFI_EVENT_BEFORE_EXIT_BOOT_SERVICES_GUID > > > > > > MdeModulePkg: Notify BeforeExitBootServices in > > > CoreExitBootServices > > > > > > OvmfPkg: Introduce CocoDxe driver > > > > > > MdePkg: Introduce the MemoryAcceptance protocol > > > > > > OvmfPkg: Implement AcceptAllUnacceptedMemory in CocoDxe > > > > > > OvmfPkg/PlatformPei: SEV-SNP make >=4GB unaccepted > > > > > > > > > > > > MdeModulePkg/Core/Dxe/DxeMain.inf | 1 + > > > > > > MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c | 6 > > > + > > > > > > MdePkg/Include/Guid/EventGroup.h | 5 + > > > > > > MdePkg/Include/Protocol/MemoryAcceptance.h | 40 > > > > > +++++ > > > > > > MdePkg/MdePkg.dec | 8 +- > > > > > > OvmfPkg/AmdSev/AmdSevX64.dsc | 1 + > > > > > > OvmfPkg/AmdSev/AmdSevX64.fdf | 1 + > > > > > > OvmfPkg/AmdSevDxe/AmdSevDxe.c | 55 > > > ++++++- > > > > > > OvmfPkg/AmdSevDxe/AmdSevDxe.inf | 3 + > > > > > > OvmfPkg/CocoDxe/CocoDxe.c | 174 > > > > > ++++++++++++++++++++ > > > > > > OvmfPkg/CocoDxe/CocoDxe.inf | 46 ++++++ > > > > > > OvmfPkg/IntelTdx/IntelTdxX64.dsc | 1 + > > > > > > OvmfPkg/IntelTdx/IntelTdxX64.fdf | 1 + > > > > > > > > > > > > > > OvmfPkg/Library/BaseMemEncryptSevLib/X64/DxeSnpSystemRamValidate. > > > > > c | 24 ++- > > > > > > OvmfPkg/OvmfPkgIa32X64.dsc | 1 + > > > > > > OvmfPkg/OvmfPkgIa32X64.fdf | 1 + > > > > > > OvmfPkg/OvmfPkgX64.dsc | 1 + > > > > > > OvmfPkg/OvmfPkgX64.fdf | 1 + > > > > > > OvmfPkg/PlatformPei/AmdSev.c | 5 + > > > > > > 19 files changed, 366 insertions(+), 9 deletions(-) > > > > > > create mode 100644 > > > MdePkg/Include/Protocol/MemoryAcceptance.h > > > > > > create mode 100644 OvmfPkg/CocoDxe/CocoDxe.c > > > > > > create mode 100644 OvmfPkg/CocoDxe/CocoDxe.inf > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > -Dionna Glaze, PhD (she/her) > > > > -- > -Dionna Glaze, PhD (she/her) -- -Dionna Glaze, PhD (she/her) -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#96095): https://edk2.groups.io/g/devel/message/96095 Mute This Topic: https://groups.io/mt/94544528/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
© 2016 - 2024 Red Hat, Inc.